Interesting. Some other stuff maybe you could try.

Aero on/off while in game, any difference in input lag

Setting system clock to 0.5ms

Disabling HPET in bios

disabling hpet gives me fps drop to like 200

Did you try toggle com_idlesleep while hpet off?

i have it enabled always because I do not get stable 250FPS otherwise.

I've just tested: with HPET ON and com_idlesleep 1 I have 250fps but microstutters annoy me.
So I always play with HPET OFF and com_idlesleep 0 and have stable 250fps too. Try it and may be redone your test if u feel better or same at QL with HPET OFF and com_idlesleep 0.

I already done all this couple months ago. HPET ON com_idlesleep 0 is best for me - no stutter smooth as butter and lowest frametime variance when measured by fraps.

Is motherboard your by ASUS?
Thanks for tests. Very usefull info.

btw I hope your are not mistaken (wrong) like with prerendered frames.
http://esreality.com/post/2640020/re-frame-me...pid2639611

the thing is I just can not normally play with HPET OFF or com_idlesleep 1. I get unstable framerates and loads of stutter.

EDIT:

so I tested it. HPET OFF = stutters + drops in frame rate + it adds HUGE input lag variace - I made 10 measurements and it was anything from 26ms to 90ms (!!!)

however DPC latency is lower - around 10us instead of around 50us, but I do not play DPC latency I play QL :D

I have downloaded some program and checked my DPC latency, its ~90 us. its normal?

I think it is all imagination of unprofessional people. As long as you do not feel stutter, choppyness and input lag it is allright. So forget about that DPC crap. Only thing that might be usefull about that if you get there like several ms spikes, but in that case I bet you will feel it ingame without any assistance.

This HPET option is the best thing to be debunked from your testing. I stupidly had this off upon reading numerous posts that it was suppose to be smoother and provide higher frame rates. I have a much more stable frame rate in ut2004 now that I've turned it on and it consequently feels smoother overall over long periods of time. I haven't tested QL yet though.

does hpet off cause you similar issues in CSGO? I've been using off for a long time now because it's recommend in so many forums, but if you say it was worse in GO for you, I'll make the switch tonight and give it a whirl.

the main problem with HPET for me is that if it is disabled I do not get stable FPS in any game. FPS dips => big input lag varience, just because you see less frames.

So main thing is to keep an eye on your FPS value, it should not have dips below desired FPS value at all.

I heard that those in-build scaling options in xl2411t like 17"/19" with 4:3 aspect ratio still add some input lag. No lag in your testing for this options?

I did not test built in scalings because I find them usless. You can simply set desired resolution and turn off all scaling and it will be 17" or 19" whichever you want.

I am using option "Aspect". My ingame res 800x600, it's 4:3. does it gives imput lag too?

So you say you read ~24ms lag at 250 FPS and ~32ms at 125 FPS?

That's really interesting. It's around 6 frames at 250 and 4 at 125.

> Average overall input lag measured from led lit to rail trail appearance on screen is 28ms with variance from 24ms to 32ms.

So it's 28ms (at 250fps) and 32ms (at 125fps). It's looks like correct coz one frame render at 125fps is 8ms and 4ms at 250fps. 8-4=4 :)

How bout dual setup 2411t vs 170hz crt, and again with 2411t lightboost?

em, what do you mean by dual setup? I plan to make it for lightboost tomorrow.

dual monitors rendering vs single monitor.

Run 2 monitors at the same time so that you can watch the actual delay happen.

this is not correct measurement because images are not refreshing syncronously on the monitors and there is no way to syncronize them. There is huge article somewhere in the internetZ where they properly measured CRT input lag with osciloscopes etc, it was around 0.5ms, this benq has 1-2ms.

What's the delay between the mouse button being pressed and the LED going on? What's the variance?

thats the time needed for the led to turn on which is something in range of 1..50us.

The response time of an LED is microseconds, but I mean the rest of the mouse. 5-10ms?

no idea

Well if you film pressing the button with something besides your finger, you can at least see if the lag is over 1ms.

If you can access audio data, can you measure the delay for QL to produce a sound from an input? Sound travels about 1 meter in 3ms at sea level. The delay is probably different than visual, and might not even be synced with the fps. It's also interesting because people have significantly faster response to sound than visual cues. /s_mixahead .14 is default, and changes the sound delay.

Cool experiment by the way.

not sure if I got you correct. Did you want me to measure the time between physical button actuation and led response? If so I've done it, its less then 1ms. Actuation and light from led are always at the same frame.

Unfortunately my camera (Casio EX-FH25) is not able to record sound at high fps.

And I actually plan to perform straight mouse click delay test. Currently I am trying to find the easy way to determine click signal from the mouse in USB cable directly without involving software.

That's basically what I meant. I wasn't sure if it was clear from the video or if you were just using the LED as time = 0.

How did you attach the LED to the mouse switches?

by soldering it to the switch contacts? :D
(with resistor and battery to light it up ofc)

:D

s_mixahead 0.10 is like a whole different game ;)

if theres no difference between 250fps and 125ms then the delay comes from non-quake related stuff (like windows / mouse drivers / mouse buffer etc).

----
btw can you also check ut2k4 on default settings? :D

there is the difference, but its very tiny, which is because 1/125=8ms and 1/250=4ms. So 4ms difference when full lag is around 30ms won't matter that much.

Well I need to find it first :) I wanted to test CSGO too just to compare results with those of blurbusters site.

same story bro, QL isn't the thing that causes the lag.
It's just what needs to happen "before quake is reached" that takes around 20 ~ 24ms.

well it is kinda obvious. I actually expected to see around 15-20ms, not 30ms. But good thing about it is, that it is extremly consistent, like more than 80% are 27ms,28ms,29ms (for LCD).

I actually expected to see around 15-20ms, not 30ms

It is probably because of high button lag on zowie.

ec2 itself has input lag

yes ofcourse, that was the whole point of this thing - to measure full input lag.

Nice. You've pretty much confirmed the testing done by Anandtech a few years ago.

One thing I'd like to see tested is if there is any lag introduced via the monitor's built in LCD overdrive feature (my samsung 700d has this) as mentioned here.

you are not going to have 1ms gtg response without overdrive, so I doubt that disbling it will do any good to responsivness. However I will check this.

response time =/= input lag.

better response time = faster frame is drawn and finished frame stays on screen longer within given refresh interval

Can I ask you to test inbuild scaling too pls. (atleast 17-19" with 4:3)
Not all games let you have desired resolution without picture being stretched keeping the prefered aspect ratio, so either monitor or gpu driver scaling needs to be used in order you want to play smth like oldschool 800x600 res on a widescreen monitor. There are still plenty of ppl who prefer to play this way and threads about gpu vs monitor scaling can be seen regulary so i guess they will also appreciate info about input lag introduced by this monitor when using scaler.

you should test some of r0achs bios tweaks and see if they have any effect - http://www.overclock.net/t/1433882/gaming-and...ch-edition

yes, do this if you have time.

he also says that nvidia drivers add a lot of lag and he only uses version 186.82 if you could test that

The newer drivers are fine with input lag. Some of the best I have seen in years. I tested 337.88 and I was getting 3-7 us(whatever that means) with dpc latency checker. I had hpet off with these tests. With it on it was between 30 and 50. I actually prefer to have it on for gaming.

my us is ~90, is it effect my QL feeling?

That should be fine but you want to shoot for 60 or less with hpet on. You shouldn't have any problems unless it goes to about 150 while your computer is idle. If you tell me your what parts your pc has I may be able to help lower it by a little bit. But again at 90 you shouldn't have any problems.

yaeh i jumps to 500-700 once in 5-10 seconds. intel i5 with intel HD and gf gt540m, I think two cards can give a big "us" time. btw I dont know what is hpet, never checked it in bios, dunno it's set on or off by default.

I don't really know much about how using a laptop effects dpc latency. I am assuming the M at the end of your graphics card stands for mobile. Also to test what your dpc latency is idle you need to have backgrounds programs off and no audio or video playing. You can open the bios and disable the intel graphics. But I don't know exactly how to do that. I would need to first know if you have a laptop or a desktop and second what brand is it if it is a laptop. If it is a desktop You may need to find out what kind of motherboard you have. It likely says the brand when you boot the pc up.

yo my latency is fucking 1000, wtf do i do lmao. https://i.imgur.com/dNpErnJ.png

thanks for the laugh.

14) On-board audio - Disable. Enormous input lag.

what

Read his posts on OCN, the hardest part reading him is always to refrain yourself from replying.

LOL such a bs post.

But I did test that, put all options how he suggests.Did not find any measurable impact on input lag. The only option that had influence on input lag was HPET OFF. It made lag unstable 26-90ms.

Yes please test CSGO I'm curious.

plz test DPI steps on zowie

ohnooooo, is this the end of the zowie hype?

i dont want a mouse with input lag :(

THEN YOU WILL HAVE NO MOUSE

i could still go from ec1 to g400s, but i dont want the added weight :(

I am planning to do same test with g500s and I will buy g100s because it is very cheap and tests claim to have it very low latency clicks.

Buy Logitech G100S please! Thanks for showing us your data on input lag so far.

Yes, please test with g100s!

please upload the footage n1.

would like to see some adns 3090 tests.
because of ;

http://www.overclock.net/t/1440395/avago-3090...he-kana-v2

here we go, footages are in the initial post

what is that test actually good for?
i tried similar things to compare the input lag of various mice, but it wasn't accurate enough.
(500fps in q3 + 1000fps recording)

>what is that test actually good for?
I wanted to estimate input lag value and to check all those retarded posts about disabling HPET etc to reduce lag.

>i tried similar things to compare the input lag of various mice, but it wasn't accurate enough.
you can not measure mouse lag strightly this way, but you can compare mice to each other. If their result is ±3ms you can safely assume, that those mice have same click latency. On the other hand if one mice gives you 10ms input lag more you wouldn't want to use it.

What do you think about r0ach?

he is paranoic I guess? :-)

=DDD

updated initial post

you forgot to test application experience when you tested print spooler.

:D
I actually put all that crap (nn7-15) alltogether and done it in one run )

instant mode doesnt do anything, whaaaaaat??? I think your doing something wrong because all the tests on the internet, even chief from blurbuster say otherwise. Unless it's the monitor themselves that are making things low input lag and instant mode has no effect? Thx for these tests btw.

EDIT: Just a quick google search showed instant mode lowered 15 - 20 ms of input lag to 7.1 -5.5 ms. http://www.trustedreviews.com/benq-xl2410t_Mo...nce_Page-2 .Something is not right.here

this monitor does not have this amount of input lag to start with. Also I could not find the method they used to measure it. If they used side by side with CRT and single timer method, this is just incrorrect data. To obtain accurate measuremnt with side by side setup you need to use this method - http://www.tftcentral.co.uk/articles/input_lag.htm . And even using this method you have to perform shit loads of measurement with cable replugging to randomize sync delay. Considering the quality of given article I seriously doubt they did this.
And those who used it for this monitor and its analgue from asus measured 2 and 3 ms input lag respectivly. Also 15-20ms change in input lag with toggling one option is pretty noticable without any equipment. This just does not happen with this monitor. Also having tried G520 CRT I could not feel pronaunced difference in input lag. If it had even 10ms this would've been noticeable.

Anyways I was going to make more measurement for instant mode off so that I could see more accurate avg value.

Also I could not find the input lag measuremnt for xl2411t on blurbusters.

This was the test i was talking about - http://forums.blurbusters.com/viewtopic.php?f=5&t=389 . But don't worry it wasn't chief who said it and it's probably innacurate. Also i remembered it incorrectly and thought it was about instant mode and not gsync.. Sorry, wasn't trying to waste your time.

noneed to be sorry. More people doubt the more I recheck measurements hence more accurate data we get.

So I rechecked instand mode influence.
It does reduce input lag for colours by 7ms.
It does not affect grey input lag.

You can find image in my main post.

would you have possibility to measure input lag on windows xp newest nvidia driver?

no all this is very time consuming. Not going to test it on XP. Might do it for 8.1 in future.

ok i didn't mean all of it, just vanilla, one try, you already know what doesn't affect it from these findings.

It doesn't matter anymore i guess, would have just been fun to actually see the proof.

link to XP download?

imsg, yes?

kk

can you test the max pre rendered frames settings at a framerate closer to the hz, like 125fps at 120hz?

and the zowie dpi steps? someone on ocn has tested this and the 450 dpi setting is supposedly up to a 1 frame (up to 8ms) slower. would be interesting to see if your results matched up.
http://www.overclock.net/t/1411332/mouse-butt...t_22619911

you think the zowie button lag is adding to the measurements? http://utmalesoldiers.blogspot.com/2013/02/114.html

Button lag is adding to the full input lag directly. However it will depend on the time relative to the current frame ie you press mouse1 in the end of frame display it will be x input lag, you press mouse1 in the beginning of the current frame it will be y. Y-X will be ~7ms. However when alot of measurement are done this factor should be excluded mostly, because it will be random every time so AVG values should represent difference in latency of mice.

DPI steps of zowie do not affect button latency.

Considering button latency - I baught g100s and will check system input lag with that mouse. Nearly all test claim g100s has lowest button latency. So if it is indeed lower by atleast 4ms we will see it immideately. If the data in that table is correct, I should easely see 15ms difference. Also zowie could have fixed this actually since i have 2014 ec2.

Also I will have access to soldering station only on mondey so I messed around with g100s abit today comparing reaction time results in http://www.humanbenchmark.com/tests/reactiontime/index.php
My guess was if zowie had more latency of the botton it should result in the situation where lowest values I can get will tend to be consistently higher with zowie. So I did perform 50 test for both zowie and g100s.
With g100s I was able to consistently hit ~10ms less at lowest.
With zowie I could never go under 158ms, most of the lowest values were 162-168ms. With g100s I hit 150-160ms range alot. This include button actuation times ofc, but still I can not wait to test g100s with led.

PS these http://www.overclock.net/t/1411332/mouse-butt...t_22619911
are correct measurements.

i forgot you were just testing with the button/led. i meant testing the zowie dpi steps with motion tests if you were up to it.

so I did the start motion lag test with same setup as here
http://www.overclock.net/t/1411332/mouse-butt...t_22619911

I got 15ms (2 frames) for both zowie ec2 and g100s.

max pre render frames only works for direct x and can make a big difference.

oh that is probably true, since QL uses opengl

it indeed only works for directx games i forgot that. i talked to the creator of nhancer a few years ago, he told me prerender does not add input lag iirc i have to find the link back.

How could you explain then: i used to play with default max prerendered frames set to 3 in nvidia on WinXP and changin this to 1 made a crucial and noticible difference in mouse response not only in directx games but in ql aswell.? Its 100% not placebo cause ive tested that plenty of times playin same opponent on eyetoeye shaft only or for example thunderstuck rail only and each time changin this setting from 3 to 1 instantly felt more responsive resulting in a bit different average hit %.. So it can be told from those tests that not only my subjective "feel" but also stats approve strange perception that directx setting affecting opengl application is actually true.

"It only works in DirectX games, not OpenGL games." it is from http://www.tweakguides.com/NVFORCE_6.html

I've used the older nvidia drivers with xp and i'm pretty sure they made a difference too. I'm pretty sure the older drivers said prerendered frames work with opengl.

Sorry dude that site is good. Nvidia had the owner of the site make optimization guides for http://www.geforce.com/ his name is Koroush Ghazi. He wrote most of them up until late 2012.

If you are anonymous Comment #8 I remember also a test someone did awhile back proving prerender 0 did have an effect compared to 1 on input lag. As for it only working directx games, maybe that has always been true, i can only prove by hitcolor and sound of lg of it being more responsive.

I would suggest to check highest graphical settings vs lowest. Then separately Anti Aliasing maybe.

this wont make any difference if fps are maintained at 250. FXAA will add couple ms maximum.

don't think that's right at all. try msaa.

msaa adds noticeable input lag (i would guess 15-20 ms) even when the framerate is the same, i don't think nvidia's csaa does though.

csaa is msaa plus coverage samples though.

Another things that you could check are mouse drivers (especially synapse) and raw input in csgo which is said to increase input lag.

I upgraded from GTX 560ti to GTX 760 and tried gpu scaling, enabled c-states, other things and hpet and it was actually much more responsive than before.

There was something seriously screwed up with my previous gpu.


You should make a note that frames to render ahead do nothing in QL because its openGL, they make big difference in almost all DirectX games.


Test windowed mode with aero on and off

>Test windowed mode with aero on and off
what for?

Test input lag of QL in windowed mode(with aero on and off) vs fullscreen

do you play in windowed mode?

in osu yes, but not in other 99% of games, just curious how much input lag it adds

i will test OSU specifically in windows/full screen and aero on/off while windowed

it's no secret that aero adds alot of inputlag, so i don't know what your after.

I don't think aero on/off is always good enough.

I think you should also disable the windows service: Desktop Window Manager Session Manager

I was still getting input lag on dolphin (emulator) with aero disabled but disabling this service fixed the issue. Maybe it's not a problem for any other application...

If you have the time (and the equipment) i would like you to check on the mlt04 sensor (wmo, ime) against either the g502, g402 or da 3g. Some people on oc.net are claiming it's more responsive than the g502, g402 and da 3g which are all supposed to have no smoothing but i think the sensor position of the mlt04 mices are playing a role here.

Some sources -
http://www.overclock.net/t/1500836/smoothing-...t_22539805
http://www.overclock.net/t/1504917/logitech-g...t_22652804

I can not find where to buy WMO in Russia. Any advices where to order it worldwide?

As for other mice you mention, I am not going to spend money on them because they are too heavy for me. Also I owned Razer mouse once and I never gonna use it ever again.

http://www.ebay.com/itm/221145782309 . How much for g502 in russia? i can send money thru paypal.

Around 100USD. Better I make order in local internet shop and you will pay with your card so that you know for sure what are you paying for. If your are interested in this contact me over pm service and we will arrange this.

he can't compare the sensor behaviour with this test.
only the button response time, which doesn't say anything about how responsive the sensor is.

i made an approach here: http://www.overclock.net/t/1490440/input-lag-...t_22311815

I did follow your approach and tested ec2 evo and g100s, see my initial post. I am adding new info there.

well, my conclusion was, that the test wasn't accurate enough, to tell anything about the sensor responsiveness.
also the test from the other guy(HAGGARD) can't be very representative, when the holy grail of sensor responsiveness (MLT04),places the same with the EC evo CL, but probably also with every other mouse(also those who are said to feel bad[DA 2013 anyone?]).

for absolute mouse lag measurement ofc its bad. But who cares for absolute? All we need to know is overall lag (which measured with decent accuracy) + relative between different mice and monitors.

of course it can only work to compare different mice, but there it is not accurate enough to conclude anything.

MX518= in the range of ~7ms
WMO = in the range of ~15ms
EC evo CL = in the range of ~15ms
all other mice = probably in the range of ~7ms to ~15ms

and what do we gain from this knowledge now, when the said to be most responsive mouse(WMO) is most likely in the same range with the said to be weirdest mouse(DA 2013)?

ah regarding start motion test yes. But the thing is its 1 or 2 frames response time. So you do not need accurate results because it does not matter if mouse have for example 9ms or 12ms, reaction for both of those will appear on second frame most of the time. Ok maybe 9ms mouse will appear nearly always on the next frames and 12ms will fall in to the second frame sometimes. And we actually can do accurate enough relative measurements, but we need to make footages of 100+ moves for each one to randomize input time relative to the current frame draw state and then analyze all that bunch of info. But I honestly not nerdy enough to dive in to that shit.
Also having read numerous posts about mice "responsivness" I have a very strong feeling that there are at least 3 factors in it:
1. People say that it is responsive because mouse1 has less delay but they are not realising it conciously.
2. Lighter mouse will always feel more responsive.
3. Same mouse put on different mats will have different starting friction and tracking friction which affect subjective responsivness perseption as well.

Many people claim WMO to be king of responsivnessm but with given data of 15ms start motion and 23ms click delay I do not see how it is better than all mice. Sure it is a good one and may have some special sensor "feel", but by no means it is the best judging by specs and tests.

>all other mice = probably in the range of ~7ms to ~15ms
I actually only saw one mouse - MX518 with 7ms start motion response time.

I think the forward sensor position gives the illusion of more responsiveness, as the mouse will be a bit more sensitive than a mouse with a more central sensor at the same cm/360.

I personally find lower CPI "feels" more snappy, or at least certainly has a different feeling as well. e.g.: 400 vs 800 on G400.

And yeah, it's very light. Pretty much as light as it gets relative to size. Feels about as dense as my G100 with the weigh removed.

All these probably contribute to the perceived "snappiness" vs other good mice.


I got a little obsessed with this whole "smoothing" controversy a while back and dusted off the old CRT to see if i could detect a difference.
WMO with a Deathadder cable, 89g G400, 69g G100s, all at 500Hz, all mice sanded on the bottom with WMO-shaped teflon feet, on a CRT@150Hz, holding each mouse with thumb perpendicular to the sensor.
I couldn't for the life of me tell a difference doing fast 180 flicks in quake. The sensors have a different feel, and the MLT04 definitely is my favorite, but I didn't find it any more responsive than those Logitech's myself.

Click latency on the other hand, I can easily spot. I remember having to lead slightly ahead of target, when sniping a 300kph+ flag carrier perpendicularly in Tribes when using my Deathadder, whereas with the G400 I could point and click.

>I remember having to lead slightly ahead of target, when sniping a
>300kph+ flag carrier perpendicularly in Tribes when using my
>Deathadder, whereas with the G400 I could point and click.
that is actually 100% true, I just realised that with zowie I had to do this too. And some rails were not connecting when I was absolutely sure that I clicked at dead center of enemy model. I played around 10hrs already on g100s and it is - point and click, not vice versa. And rails through are gone completely.

I have the g400 v2 and can confirm what you've said regarding low CPI feeling snappier.

I've also tested 400dpi to eliminate +ve accel when compared to 800dpi (I use a ss heavy cloth pad). I found the difference being about 1.5cm between slow(28.5cm) and fast(27cm) 360 turn at 800dpi.
I thought this would probably be due to 400dpi being closer to 1-1 dots-to-pixels required for my resolution, fov, and cm/360. Or it could just be my clothpad, either way I feel a lot more confident with mouse tracking now.

did not find any accel in my g100s though

Good to hear. I'm edging towards buying a g100s now. The only thing I'm worried about is the lower max speed on it compared to g400 as I like to make pretty fast movements.

I measured 3.7m/s in enotus test. I am not low sense though. 2.6 sens 0.2 accel for 420DPI (using recalculated yaw and pitch for g100s ofc since it has around 1000DPI at default)

I don't think you will have problems:

https://www.youtube.com/watch?v=flMZdk0LrKg

holy shit, that is some serious setup there. That is exactly why I added accel after using ~40cm/360 for like 3 weeks :D

I actually only saw one mouse - MX518 with 7ms start motion response time.

that's my assuption, that if you test all mice available, some will also have a motion response time at 7ms, and the rest(with a few worse exceptions) will be 15ms.

that's not a very accurate comparision of different mice, when there can only be two results, and when a mouse gets the bad result, it still doesn't say anything about the quality of the sensor(still having the WMO in mind, which will never be seen as unresponsive).

thats not very accurate indeed, but it is better then nothinkg

As stated by HAGGARD in the OCN thread, the responsiveness is not only determined by start motion latency, but there could be more delay for continuous tracking. That would show up when you look at when the mouse stops moving vs. when no new frames show up on the monitor.
Smoothing or interpolative measures can only be applied throughout mutliple data points, so it wouldn't necessarily show up as latency for the first registered movement.

that's true.
i also tested it with different values of "m_filter", and it didn't affect the results.
but with the equipment used, it is impossible to detect the "smoothing" within the movement of the mouse.

my point is: if it can't, then it's useless.

Also actual DPI value for my mice are
zowie 421dpi
g100s 937dpi
How did you know its not 450 and 800 dpi? Any software to measure that?

measured cm/360 with ruler and calculated with this formula
DPI = 360*2,54 / (cm360*m_yaw*QLsensitivity).
It is pretty accurate as I transitioned from zowie to g100s without any adaptation time using new m_ya and m_pitch values derived from this formula.

Original source for this formula is http://www.funender.com/quake/mouse/index.html

Cm/360 is innacurate afterall involving much human error so doubt you could state its 937dpi but not 911 or whatever within 5-10% human error

I have 1mm lowest grade on ruler. So I do not see how it is 5-10% inaccurate.
If we take 1mm error it will be 0.263% of 380mm for 360 movement.
Hence error for 937 is +/-2.5DPI. So we can safely aasume that it is 937+/-5DPI because my ruler could have error itself.
Also 911 vs 937 is actually noticeable for me. This is the reason I had to make exact calculations so I do not have to adjust to new sens. It is especially important for me because I use accel.

if you're using your hand/arm to move the mouse, you could be changing the orientation of the mouse ever so slightly.

well this is good point, ill measure what error slight orientation change is generating.

"1. Maximum prerendered frames setting in nvidia control panel (because it only works for DirectX and QL uses OpenGL)"

Actually that statement is absolutely wrong. "Max prerendered frames" is OpenGL feature. It is known as "ogl_maxframesallowed" on Linux, where, you know, only 1 graphics API and it is not DirectX. If you really want to test its influence on latency you should use more or less modern OpenGL engine like UE3, idtech4/5, DarkPlaces (Xonotic), QFusion (Warsow).

Quake doesn't a have that setting. He says he has counter-strike which is direct x. Why would he mess with linux and and those games when he just needs to set it in the nvidia control panel and test it in counter-strike. I am sure the input lag would be almost identical.

we will see, going to fianally proceed to CS this week

You didn't get my message. I just say that his statement is wrong in the 1st place. And it might be just too old OpenGL version of QL engine, which doesn't support "Max prerendered frames" feature, not the whole OpenGL it self. And I haven't asked him to try Linux.

Just to let you know that QL uses idtech3, which was released 15 years ago!

removed incorrect statemnt from initial post.

https://www.youtube.com/user/CrazyRussianHacker

this is u ok

bingo :D

This guy is a thousand thousand times more useful than that guy.

It seems there are so many variables of driver settings, driver versions, game settings, frame rate, refresh rate, game engine + hard coded flip que/pre render frame settings and poor information documenting the effects or correct configuration.

I can remember why I gave up the last few times trying to fully understand pre render frames and why it affects one game and not another.
the net is full of contradicting or incomplete information on this subject.
even worse are posters trying to pass placebo as fact or expecting everyone to suffer the same problems they do ;

Did you enable HPET only in BIOS? Or on Windows too?

"By default Windows 7 uses different timers in the CPU to calculate stuff. HPET is the newest and best of these timers, but because of default combination of timers it takes longer time for CPU to keep up all the timers and sync between them. Forcing Windows to use HPET only improves performance and leads to greater FPS.

Steps to enable this tweak:

1. Enable HPET in BIOS. If you have HPET option in BIOS then your hardware can support HPET.

2. Enable HPET in Windows by giving this command in admin credential CMD:
bcdedit /set useplatformclock true

3. Reboot "

It would be interesting to get results from all 4 possible configurations. Here is useful thread about it: http://www.neowin.net/forum/topic/1075781-twe...e-and-fps/

nice. Going to test HPET ON in BIOS + enable it in Win 7.
My current tests are done for default Win 7 configuration with latest updates and I obviously have issues with framerate when I disable HPET in BIOS which is causing unstable input lag.

updated initial post with g100s results.

So Zowie EC2 CL turned out to be not so good compared to G100s. Especially considering that they did not improve button latency from their 1st mice at all. Pretty sad because everything else in this mouse is great.

Could you test non native DPI's?

maybe laters

shit. took back IE3 from my trash today..

so zowies do suck, now im depressed. what to get now? :x

Logitech G100S. Dirt cheap (£12 eBay, £16 Amazon): http://esreality.com/post/2640507/lowest-price-bestest-mice/

Either use Logitech G100S as-is (can remove weight for 70g mouse) or get someone like thuNDa to install the pcb/sensor/switches into any shape mouse that fits your hand best? Logitech G100S is plug and play 500hz / 1000 dpi (no flaws).

what if i have big hands? i replaced my zowie FK with ec1 evo cl because the FK was too narrow. is a g100s as wide as an ec1 or is it also narrow (ontop of being a little bit shorter, that i can tell from pictures ^^ )

Here is a mouse size chart for you to see (dunno if there is a newer chart): http://cdn.overclock.net/5/52/5266ed39_mouseSIZES.jpeg

And that is why I said G100S was plug and play (no software needed) and you can probably pay thuNDa to put Logitech G100S PCB/Sensor/Switches into another mouse shell that fits your hand, you bellend.

no, he can't. :)

:(

:D

:P

its even 20$ here on sales :D

And yes g100s is flawless mouse so far. No smoothing, no snapping, no additional lag compared to other mice, weight can be lowered to 70g, perfect tracking, perfect accuracy, 3,7m/s max speed (measured with enotus), no software needed for default, and default is flawless, ambidextrous, electronics can be put in nearly any case you like.

holy cow, 10.99 for g100s on ebay??? i bought one, but almost seems too good to be true. are we sure these are not copies?

Razer Deathadder 3.5G with 2.33 Firmware or Logitech G402.

while i appreciate the suggestions, im not getting a razer and i dont want a spaceship either :D

your loss :p

it would of been if i ordered one of those 2 ;)

g502 looks flimsy rather than a solid shell, will it just fall apart on me? i wonder how thatl work in the long run. its also somewhat heavy (not sure yet if i want to go over 100 grams of weight, but its an option)
while i do trust your judgement, that the sensor would work well etc, the mouse just looks like shit and i dont wanna risk 70 eur on a bad shape... again (FK didnt fit my hands either)

already tried a DA -my brother has one- and the shape is shit, software is shit, its razer and i dont trust that company at all :p

the only other option ive looked at so far is a g400s, also quite heavy but ive played with that mouse before for years (mx500,510,518)
or i could just stick with this ec1 evo cl, i mean whats a few milliseconds really?

G402 not 502

Ty, I derped. Both look the same though, with the 402 being a bit shorter. I dont think this will change my opinion :[

You're welcome anyway.
Also the G502 which I owned felt very solid.

1. 32ms avg for 125fps (30 measurements).

ouch, gg. :(

Try testing in_mouse "-1,1,2".
What setting were these tests performed on?

raw input

Please test the WMO or MS Intellimouse 3.0

I will.

Cool, thanks.

With 500hz pretty please.

ofc whats the point of using it at 125 )

does your bios settings have HPET with a 32bit, 64bit setting? does it matter?

no it does not have

hm mine does ~_~

From here: http://www.techarp.com/showfreebog.aspx?lang=0&bogno=415

Setting it to the 64-Bit Mode allows the 64-bit operating systems and applications to make full use of the HPET's 64-bit registers.

Setting it to the 32-Bit Mode forces the HPET's 64-bit registers to run in the 32-bit mode. This allows proper operation when used with a 32-bit operating system.

If you are using a 64-bit operating system, you should select the 64-Bit Mode so that the operating system and 64-bit applications can make full use of the HPET's 64-bit registers. There is no harm in selecting the 32-Bit Mode although it will mean a potential reduction in counter resolution and/or functionality.

ya mine was on 32. switched but its not like i have measurement tools to see if it did anything

if you don't notice it then it doesn't matter, eh?

all of this kind of stuff probably has a minor factor on play but ull never notice by feel. its placebo as all hell when people start getting into this kinda shit without measuring

could you test wmo input lag?:D (on 1000hz or 500hz)

It might be interesting how such a great (but old mouse) is compared to the new ones.

EDIT: ah someone already asked that - good :)

then ps2 (250hz ) vs usb 500 or 1000hz?

As far i know ps2 works a bit different than usb and compared to USB is based on interrupts

other way around afaik, ps/2 is interrrupt based, usb is polled, plus max ps/2 is 200hz. Feeling is much different from usb too, small movements feel a bit "stuck" etc. dno, not long ago i tried ps/2 port.

added result for G100s + CSGO 22ms avg. Pretty much the same as
http://www.blurbusters.com/wp-content/uploads...g-csgo.png except that I had alot less variance.

Thanks for this amasing tests you are doing. That is some rare tests! I hope you can test the all mighty WMO mouse or a mouse that use the same sensor (ie 3.0 or IMO 1.1).

Amasing job.

G100s \o/

About HPET: da fuck? what settings of HPET and idlesleep should be best with an i5 4570 and windows 8.1?

Thanks.

not sure about HPET in win 8. If you have stable framerate in QL like in this small pic below leave it as is.
com_idlesleep 0 always for all modern CPUs.

Thanks :)

Did you test the difference without com_idlesleep? I thought it wasn't supposed to matter unless people were having a specific issue (which I forget).

How about testing sensor responsiveness on max Hz.?

set /sensitivity 999
focus your camera on the mouse with the screen in background (similar to your test footage) and use the pen to agitate the mouse
measure delay from impact

I did that already it is called motion start lag test. I did try zowie on 1000hz and there is no difference.

Can you test max pre rendered frames thing (with cs) thanks

Tested it already. All results are in the initial post.
tldr it does not make difference

pre rendered frames only works with directx games.

CSGO is not DirectX?

It is. If you need proof look in your Counter-Strike Global Offensive folder. You will see a DirectX installer.

Then I do not really understand those Anon's questions, I have done test for both QL and CSGO. In those games I could not find noticeable impact of max prerendered frames, which means that even if it adds lag it is less then 3ms for those 2 titels.

I think he hasn't played csgo. In cs 1.6 I believe there are opengl sound options. I think he is getting confused because of this. I am pretty sure he believes the counter-strike graphics are opengl when they are actually directx.

Valve optimized CS GO for low latency, so amd users without that option in official drivers are not in disadvantage.
pre-rendered frames are very noticeable in BF4(driver setting has no effect on dx11 games, it can be changed with console command)
borderlands 2
l4d2
and 99.99% of other dx games games.

probably correct but I am not interested in those games and input lag is not as important there anyways.

TL;DR version?

Average overall input lag from click to screen
QL: Logitech G100s 15ms; Zowie EC2 CL 28ms
CSGO: Logitech G100s 22ms

6 ms difference. Basically - no difference.

In ql it is 13ms difference.

it is not a difference indeed

Thanks for testing this :)

Can you test ut2k4 and possibly a ut4 pre-alpha build?

where do i get those?

Registered members on their forums have access. Their developer is looking to tackle input lag and your feedback would be appreciated.

At the start of each new frame do:
1) obtain the raw input from mouse (and keyboard) since the last frame.
2) update the player's rotation and location.
3) start rendering.

Do not do this threaded, but enforce the ordering.
(Somewhere between step 1 and step 2 you add on the ingame sensitivity / accel settings etc.)


Ofcourse you can also do the following:
1) make a thread for reading the raw inputs which checks inputs every millisecond.

2) make another thread for rendering based upon player location/rotation which continuously runs. (while(true) .. render code, who needs multitasking while gaming hrhr)

3) start the 2 threads. (preferibly on seperate cores since that's not being used much anyway)

4) upon new input: update the players rotation and location.

5) whenever your renderer reaches the place where rotation/location are read first make a backup of the values and use those at all places where you currently access the rotation/location.

(Somewhere in step 4 you add on the ingame sensitivity / accel settings etc.)
Whatever you do... do not write many lines of code.
The UT engines are HUGE....

ok. However having read dev posts on this forum, I now understand how it is possible to fuck up modern games with shitty input. That guy obviously has absolutely no clue how to write low latency "real-time" code. Neither he has a clue how proper mouse input should be made, I just wonder is it THAT hard to hire one really experienced programmer into the team, who have in-depth understanding of such things...

And this
"appreciate your attention to detail when it comes to input."
wat? detail? Shitty mouse input in nowadays fast paced FPS game is just a "detail"...

Also this
"I'm seeing ~83 ms between mouse touch and gun reaction in UT at 120 hz. Using the same setup, I'm seeing ~133 ms between mouse touch and gun reaction in CoD Black Ops 2 PC. In a DirectX test Windows app, I'm seeing ~42 ms to ~66 ms response time. It seems like USB mice are slightly to blame, but I don't have conclusive proof yet and I'm still investigating."
:D A least he seem to be researching the issue seriously now

EDIT: Seems like that guy from UT dev team found the problem and fixed it, because I measured 17-26ms of lag in UnrealTournament.exe 19-08-2014 with g100s

That post read as a acceptable result. lol

The timing of this and that thread are perfect :) Good work.

hehe, kinda true...
But UT kinda has made it famous to write extremely shitty code with a lot of people. And then create a very good interface for it and use great artists to make it look acceptable.

I always considered UT as an engine awesome for developers, horrible for players.

Ahh, sorry... I don't mean the GUI but I mean the implementation interface etc. Which makes it easy for developers/artists.

updated initial post with ut result

So they are 1 frame slower than QL... that would be acceptable to play on. They could probably spend a bit of time to reduce it 1 more frame but it would be ok.

It's strange that the developer in that linked forum would say "How are you measuring this? I'm using an LED soldered to the left mouse button switch and a high speed camera. I'm seeing ~83 ms between mouse touch and gun reaction in UT at 120 hz. Using the same setup, I'm seeing ~133 ms between mouse touch and gun reaction in CoD Black Ops 2 PC. In a DirectX test Windows app, I'm seeing ~42 ms to ~66 ms response time. It seems like USB mice are slightly to blame, but I don't have conclusive proof yet and I'm still investigating."

I would be interrested to see the old UT2k4 results as people (including me) always said that it was delayed too much :p


Also! Could you do (in UT) "bind left mouseButton1" and doubleclick it to see if movement is equally responsive?
(take the time from the 2nd click and compare it to when the jump starts (screen should start to move up a bit).)

copy paste of couple of posts from that board #1
I'm not a coder or anything but I could make sense of some of the ue3 code in some of the classes. One big problem you have in that engine, is that with a certain low sensitivity, you can make the mouse somewhat not pick up very slow movements. In my research I found out it has to do with storing the rotation as integer value. That basically means you lose all decimals when using non whole numbers as sensitivity because that conversion is just rounding down to the next lowest whole number. One would think to just use whole numbers as sensitivity then but the problem is horrible FOVscaling which takes 90fov as the base and multiplies your sensitivity, resulting in a non whole number again (even when using fov 90, lol). The problem where you can make your view not move with very slow movements is caused by hitting a sensitivity below 1.0 which becomes zero when converted to integer. You might say <=1.0 is really damn low but in fact it isn't! It can easily be hit when zooming comes in to play because FOVScaling multiplies your sensitivity, effectively lowering sensitivity the lower your FOV is. That is very problematic for low sens players who want something like 50cm/360 or even lower. You run into problems already using a 380dpi mouse so with higher dpi you would have to lower your sensitivity even more! And let's be realistic here, for todays standards 380dpi is damn low. I would say average dpi nowadays is around 1800dpi which makes your range of usable sensitivity in ue3 even worse.

I've no idea when and how exactly ue3 samples input but a wild guess would be every frame. The problem is depending on the speed of mouse movement, different amounts of data are sampled and converted to integer. So if you move your mouse a fixed distance, one time fast and one time slow, you get the counts from the mouse in different chunks. With the conversion to integer, you lose different amounts of data when comparing slow to fast movements. I guess that's a cause for slight acceleration.
Edit: An example: Your sensitivity is 1.5. You move your mouse 2 dots/counts. Once moving that distance fast within 1 frame and once a bit slower within 2 frames. The latter should result in 2 times 1.5 rounded down to 1 so in total 2 worth of ration information while the fast motion should results in 3. That would mean depending on fps, speed and distance of a mouse movement, you will get totally different amounts of rotation. Just a theory and I hope my explanation makes sense

Quote Originally Posted by knepleyp View Post
bEnableFOVScaling is just a linear scale and not acceleration. It's there to make sensitivity lower as you go to a lower FOV so things like sniper zoom wouldn't need a separate sensitivity. That's more of a design discussion than a tech problem though. I don't think that's causing the current issue people are seeing.
I'm sorry but fovscaling is just a horrible design decision and a tech problem at the same time. Yes, from a users perspective it makes things easy because the average player doesn't have to mess with sensitivities for zoom but what if one actually wants a totally different sensitivity while zooming compared to what FOVscaling gives him? You could just bind setsensitivity on your zoom button or something but that in itself causes other problems, especially when you want some sort of zoom toggle and not hold to zoom. That's why a seperate zoom sensitivity or zoom scaling factor cvar is superior in my opinion. Problem is the sniper rifles incremental zoom (you still have that in ue4, don't you?).
A zoom sensitivity setting overall is superior compared to fovscaling because it gives you more control over how you want things to react and is easier to use compared to making yourself a sensitivity script/bind, which you would have to do if you wan't a different zoom sens than what fovscaling gives you. Those are just the usability problems, the technical problems are described in the first big paragraph.

I don't know if the stuff I wrote actually applies to ue4 but I thought I would share the results of my research regarding mouse input in ue3. In more detail with code snippets HERE.

#2
On shot inaccuracies in UT2004 by Lotus+
"In ut2k4, when you fire a shot, the shot is not only not guaranteed to be fired when you shot, but also is not guaranteed to be even aiming in the same direction, or from the same place as you shot. For example, if you move your mouse *QUICKLY* from left to right or up to down. There is basically a random cone of fire, even on weapons like the shock rifle and lightning gun, and even on lan.

Here are the 3 easiest ways to visually show yourself both effects(position and rotation).

Method One (movement):
1) Load Stock UT on any dedicated server (NOT INSTANT ACTION)
2) Go to deck17
3) Go to the ramp in the main room closest to the shock elevators... start walking backwards up them.
4) Aim at the very top of the boxes directly in front of you.
5) When you fire, it will miss, even if you keep your crosshair on the boxes the entire time.

Method Two (movement):
1) Load Stock UT on any dedicated server (NOT INSTANT ACTION)
2) Go to any map
3) Have your partner in crime stand still anywhere on a flat place
4) Go to one side of them, do a standard dodge(not a dodge jump for simplicity) and fire exactly as your crosshair crosses them, don't actually aim, just fire as your crosshair passes them.
5) When you fire, you will miss quite often even on perfect shots.

Method Three (rotation):
1) Load Stock UT on any dedicated server (NOT INSTANT ACTION)
2) Have your partner in crime stand still anywhere on a flat place
3) Do a really fast snapshot while standing still and stop your mouse every time BEFORE you reach your target
4) You will hit your opponent quite often despite never having your crosshair in his direction.


The effects are greater when the movement is faster. In the case of rotation, you can get RIDICULOUSLY huge error in your shots, and I notice them everytime I play the game. It is *THE* reason that people are rewarded with low sensitivity in ut2k4 and it has subconsciously affected the way people move and aim tremendously as a huge huge portion of aiming is overcoming this by moving your mouse/movement in counter-acting manners. Like it or not, in ut2k4 your shots aren't going where you aim unlike ut2k3 =( “

Further newnet discussion:
http://prounreal.org/forums/viewtopi...level&start=80

On Netcode in UT2004 by dnx3
Posted by dnx3 on 5/16/04

“As far as the shots not hitting visually on your screen, but registering hitsounds and doing damage is concerned, we've noticed this way back in the very early alphas. We then spent a ridiculous amount of hours trying to figure out what was causing it, and ended up realizing that its actually a bug in UT itself, and happens just as much without Enhanced Netcode... What happens is, when you move your mouse quickly, and then fire before you stop moving on the target, (which good players will do quite frequently, I'll call them flick shots) the shot you take will not always go precisely where your crosshair is.

In our testing, we've found some extreme cases where the shot went as high as 5000 units off. An entire 360 turn in UT2004 is 64000 units wide, so that means the shot was 28 degrees off. Obviously, this is an extreme case, but there are plenty of situations where this happens, and is very noticeable at long ranges. (In fact, when UT2004 came out, a whole lot of us were wondering why our long range lg/shock flick shots weren't hitting half as much as in UT2003... It all made sense when we did that testing almost a year later. The current theory is that its part of the bandwidth optimisations that were made to handle very large player/projectile counts on large outdoor maps.)

Anyway, the reason why you don't notice when you're not playing with Enhanced Netcode is because the shot itself will be drawn off-target. Therefore, when it happens online, you'll just believe you had a small ping spike or something along those lines. (which in the ends looks identical). You should be able to notice it on lan, however. Of course, looking at a demo afterwards will not help whatsoever, simply because the shot will also be drawn off the crosshair in the demo, and you have no way to tell when the player pressed his fire key. So we assume thats why it hasn't been considered a widespread problem. But it's there.

When we figured that out, Lotus wrote some correction code, to try and minimize those off-target shots from happening. However, I do not think the code was kept, for balance reasons. (Obviously, if those flick shots are hitting as accurately as they should be, as opposed to the default behavior in UT2004, that would significantly increase the power of the affected weapons.) Plus, it didn't work flawlessly anyway. The theory there is that the netcode changes that caused the inaccuracy aren't in the unrealscript code, but in the native engine code, and therefore aren't fixable. We can only try and hack our way around it.”

Any more questions about UT2k4? :D

hmmmm who would've guessed that people paid to write computer games would be making such huge mistakes in implementing something.

Maybe they should hire a gamer who has had a good education in software programming.... if only there was such a person focussed on delays.... Hmmmmmmmmmmmm well if they really want it fixed they could over-pay me and I'll help them out hahaha :D

They need JohnYouKnowTheSurname :D
It seems like that dev (knepleyp) jumped deep into all this, considering that he managed to fix mouse1 excessive latency there is a hope that mouse motion input will be fixed too.

I don't really follow ut all that much...
So that knepleyp guy fixed input delay on mouse1 from 83 ms to 20 in a few days?
Because you say it's 17 - 25ms while he said it was 83ms. That's quite a big gap we're talking about.

It also raises the question why is it specifically mouse1 and not all input? (perhaps this is a non-existent question if all input has been fixed, but I don't know and don't have any means to test :))

according to the forums all mouse input got fixed in the last update except that mouse moves in 3-4 pixel increment. Well if the code was shitty, than 83ms->20ms is no wonder if he just made it how it should be. I doubt there is anything special with such things these days.

Well it's not that difficult to write good input code... But it could be very difficult to fix broken code. And 83ms input delay hints to very very broken code.
So I am somewhat suprised that it was fixed fairly rapid.

Nice results. Your post #213 was a bit harsh lol.

Could you also confirm whether doubling packets sent online in ut2k4 via the keepalivetime adjustment makes any real difference. I suppose this will be difficult to test because it has to deal with network latency.

ut2k4 is a dx8/9 game so it's probably a good place to also test input lag on pre-buffered frames. Again, this could be difficult to do as there's no way of locking offline fps.

I might do this later if I get right mood. I am not rly interested in testing games which I am not going to play for sure. However I will keep and eye on new UT, I kinda liked it. Movement is retarted ofc I feel like pianist but could be fun actually with all those wall jumps :)

Regarding that #213 post I did not actually mean to insult the dev, but more to point out the fail of Epic as game developer. Seriously, after I have read even more of his posts I have a strong feeling, that he is expirienced decent programmer but it looks like he develops game in FPS dgenre for the first time. I mean they design fast paced first person are shooter which is supposed to become highly competitive.
Stable engine with high FPS output, solid low latency input and accurate netcode are the core things for such game. Such things when done properly are creating solid basis for the game to last for years (QL, CS example). Yet he just discovered that something is wrong with mouse input after users pointed on this.

"Attention to detail" is a specific phrase in English that's often used in skill descriptions, job requirements, etc. Basically it means someone who will work carefully and not make or overlook small but important mistakes.

For example, a software contractor for the Mars Climate Orbiter not converting a rocket's thrust from Pounds to Newtons: http://www.washingtonpost.com/wp-srv/national...100199.htm

Another example: Searching for exoplanets but approximating the period of Earth's orbit as circular instead of elliptical (so derivatives of orbital period were wrong): http://en.wikipedia.org/wiki/PSR_B1829%E2%88%9210

He's not disparagingly referring to input lag as "just a detail", rather he's saying details are important.

I hope so :)

the only reasons I can think of you getting higher latency with gpu scaling off in the NV control panel are.
1: it's bugged /broken
2: disabling it uses your monitor's scaling which would explain the 3ms.

but it does not add lag when set to monitor scaling in nv panel. I assume that bug of driver or occasional fluctuation because of low amount of tests. I will make a bit more for that to make it clear.

Multicore rendering or multithreading in general can be the cause of latency. In OGL-based games, there is none of that, whereas DX does true multicore utilization. You should disable that in CS:GO (make sure you keep the same framerate for tests with and without multicore rendering) and check for differences in input lag.

video.txt: settings.mat_queue_mode 0 (or Multicore Rendering: Disabled in-game)
launch option: -threads 1
NVIDIA: Threaded optimization: Off
Windows: right-click on the csgo.exe process and assign a single core to the tasks of that process.

shouldn't it be enough to disable it just in the ingame options?

Maybe lol.

The input lag of multicore rendering in CS GO is pretty low. Its worse in l4d2, tf2 and others. But CS GO has really poor optimization, even with multicore on some maps fps gets lower than 120 and its only 4vs4, so it should be left on. Some guy from blurbusters tested it in cs go, got like ~4ms.
Also UE3 multicore oneframethreadlag=true adds noticeable input lag, but its required to keep fps high.


iirc launch option threads does nothing
same with nvidias threaded optimization in most games.

NVIDIA threaded optimization affects QL

in which way?

in a bad way.

leave it at AUTO.

in a bad way.

leave it OFF for QL.

is there an official guide from nvidia explaining what are all thoose settings on their drivers or wtf?

lol no ofc
You only can see description in NVIDIA control panel.

it is pretty much explained in nv control panel

Yeah, as with pre-rendering, Valve apparently optimized the game in terms of multicore performance for AMD systems. It does add latency though and frametime variance (pretty negligible though).

That's why I switched to intel. Great singlecore performance, I keep a constant 128fps with very low frametime variance, without multicore rendering that is.

Dunno about the threads launch option, shouldn't be necessary if mat_queue_mode is 0 and amount of physical cores = amount of virtual cores or threads.
NVIDIA's multithreading support is primarily designed for OGL games, or so it seems. But rarely does an OGL-based game actually support multithreading.

So yeah, like thuNDa suggested, disabling multicore rendering in CS:GO should suffice (either in-game or in the video.txt).

but disabling it lowers your fps which having lower fps itself adds more input lag

same thing as capping FPS in csgo adds input lag (this has been known since cs source by a pro team named verygames) you always want your fps uncapped (fps_max 0) in csgo or any source engine game to get the least input lag

i get 300+ fps with multi core rendering on and only about 120 with it off so im willing to bet that im getting wayyy more input lag with 120fps compared to 300 than i am from having multi core rendering on

funny thing is that I get 300+ with both multicore rendering enabled and disabled

must just be your beast CPU, i play cs a lot more than i do quake and almost everyone i know gets a lot less with it off even with decent cpu's

btw thanks for doing these tests, input lag is one of those things that always makes me paranoid as hell so seeing what gear and settings minimize it is great but i was wondering if you get the chance you could test a couple things?

DDC/CI on/off (you do it in the monitors on screen menu there should be an option for it somewhere)

m_rawinput 0/1 in csgo (not sure if you already tested this one or not? kind of confused about the OP =/ )

anti aliasing on/off ingame

these are a few of the main ones people in cs always talk about adding input lag so debunking them right here would be awesome thanks again man

must just be your beast CPU, i play cs a lot more than i do quake and almost everyone i know gets a lot less with it off even with decent cpu's

btw thanks for doing these tests, input lag is one of those things that always makes me paranoid as hell so seeing what gear and settings minimize it is great but i was wondering if you get the chance you could test a couple things?

DDC/CI on/off (you do it in the monitors on screen menu there should be an option for it somewhere)

m_rawinput 0/1 in csgo (not sure if you already tested this one or not? kind of confused about the OP =/ )

anti aliasing on/off ingame

these are a few of the main ones people in cs always talk about adding input lag so debunking them right here would be awesome thanks again man

any AA adds few ms lag.Will test m_rawinput and DDC today. And I do not have that much of a great CPU, not even i7. Mine is i5 4690.

neither DDC/CI on/off nor m_rawinput 0/1 do make any effect on input lag for click. I still get around 20-22ms on average with G100s. FXAA tends to add 1-2ms so the results are more of 21-23ms avg, however the added number is so small that I would need like over 100 measurements to rule out random factors and get the precise number and that is not what I am going to do :) Could not test MSAA since it ruins my framerates and adds even more frame time variance.

However both m_rawinput 0 CSGO and in_mouse 1 for QL gave me impression of like im playing with m_filter 5-10 or it adds smoothing, very noticeable at fast short movments its not like direct lag itself it like i get some kind of viscosity feel when using m_rawinput 0 or in_mouse 1. Not sure how to actually measure it since first response is still good. Anyways raw input seems clearly superior for me.

alright thanks for clearing that up

ive always used rawinput 1 as its a more consistant and reliable input method but people keep saying that its been "proven" to cause more input lag which i always thought was bullshit considering raw input was designed to be faster then windows input in the first place.. so yeah good to know!

to me it just seemed to be a rumour that went around, but no one could ever point to a source. I think most people now ignore that bit of advice as bad info/myth.

Props to you man, some incredibly valuable work!

That would be awesome if you could test as many mice as you can because i dont trust the japaness test sheet i found on google, think they did not made multiple pass to tess input lag of all the mice.

Must be a lot of fun to do all this tests :)

glhf!

you can trust them. Their setup is correct and their comparitive tests are far more accurate then mine. Their results have been confirmed for at least 7 mice from the list in various forums.

lightboost works by strobing the backlight after the screen is completely refreshed. watch http://www.youtube.com/watch?v=hD5gjAs1A2s#t=24

since the new information is displayed at the end of the refresh cycle, lightboost is guaranteed to add additional input lag. the additional amount is roughly 1 refresh period at the top of the screen, half a refresh period at the middle, and 0 at the bottom. on average you will see an additional half a refresh period of input lag.

-flood

except that I take footage from the bottom of the screen hence it is not adding any.

Thanks for all your work man! I would like to ask you to test Benq2411XL option DDC/CI. Actually its not meant to have any connection to monitor input lag,but i've read some people mentioned its influence on that. Havent seen any impact myself but still curious if its just paranoia or it adds some ms afterall.

Emmm did not get, how exactly am I going to test this http://en.wikipedia.org/wiki/Display_Data_Channel ?

Monitor menu->System->DDC/CI->on/off

^Test this please

You don't need to test any of these. It's just over the years i've compiled a list of myths on this matter and just thought this was a good place to post it.

List of myths -

rinput less lag/smoother/more stable than source & go's raw input.

in_mouse -1/m_rawinput 0 less lag/smoother/more stable than in_mouse 2/m_rawinput 1 (this one is interesting because 4 out of 5 players in the professional cs team called NiP use m_rawinput 0 and also rapha and cypher have recently switched to in_mouse -1).

q3 input less lag/smoother/more stable than ql input. (rapha has also said this, the biggest quake myth).

xp less lag/smoother/more stable than Vista/7/8. (rapha has also said this).

125hz more stable than 500/1000hz (I only hear rapha say this).

cg_zoomsensitivity 0 more stable/less lag/smoother than zoomsens 1 even if you don't zoom. (many pros still use zoomsens 0 but havn't heard why so maybe it's because they're just used to it, but some users have reported what i have described).

lower resolution (e.g. 640x480) less lag/smoother/more stable. (many pros still use low res).

com_hunkmegs to 56 for improved dodging (only ever heard cooller say this. Apparently qw had a bug where setting a high hunkmeg would affect sensitivity so this may be where the myth originated from). Also some ppl have reported diff sens feeling, and for some unknown cypher used to use 50 in one of his q3 configs.

(October 14 update) 102 fov best fov according to some science theory by arqon in a long gone developer thread. Reading threads nobody seems to remember much about it it but i like this comment about it - http://www.esreality.com/index.php?a=post&...pid1926606 . It may have something to do with taking 3.5 screens to do a 360 (fov 102.5 would be more accurate but maybe he wanted round numbers but still doesn't explain how he got those values).

q3 having less input lag than ql isn't a myth.

Until there is proof it is a myth.

ye especially considering that QL is entirely copypaste of Q3 in cgame and rendering part.

do the start motion test in q3. i guarantee it's more responsive.

ok I will do that, but a bit later

i look forward to finding out if i'm crazy or not.

test ioquake3 and quake3e

so I did this. Q3A seems to have 15ms more lag in mouse input compared to QL. Physics is actually noticeable different in Q3A so I bet this is the reason for those claims that Q3A is more responsive. However as I am used to QL I find that Q3A feels less responsive.

Did you try the newer clients with raw input?

I used the one which is distrubuted in steam its 1.32

Yeah, that has barely any optimisation for current hardware and software.
Most people use ioquake3 variants, rawq3 for example.

Also, the standard client utilises direct input by default, maybe you'd get a different result if you set in_mouse -1.

seems like it removes ~8ms lag, so with inmouse -1 it is ~22ms

I don't know if server settings would reduce visual lag but I do know that q3 by default has 50ms server lag while QL has 25ms.

So in Q3 you would need to set these to make it similar to QL:
sv_fps 40
snaps 40
cl_maxpackets 125
rate 25000

sv_fps is influencing viasual lag i know that, done all the test with sv_fps 125 and all other stuff, in QL visual client side part is completely server independent

Alright, could you test ioquake3 and quake3e then?

Arn't sv_fps and server lag different things? to get rid of unlagged this might work - http://www.esreality.com/?a=post&id=2110433 and for q3 im not sure.

EDIT: i'm not 100% sure on these stuff so anyone feel free to correct me.

I am not sure if sv_fps in Q3A is affecting only visual movement lag or client side weapon visual effects as well, so I did the tests on sv_fps 125 just to be sure to exclude this factor.

Regarding your question - sv_fps determines how often server is sending updated data to client. So essentially if it is set to 20 you have 50ms lag even on LAN.

Then I would like to ask you to provide proof.

cg_zoomsensitivity values having an effect on stability makes little sense since all it should do is adjust the zoom sensitivity conversion algorithm and and multiply it by a factor.

What I can say for sure is 250Hz is most stable and best choice.

For me Lightboost actually makes input feel more responsive because of reduced amount of motion blur.

didnt expect anything different from you ;p

test non native DPIs for G100s if I get a right mood

could you do this one next when you have the time?

done, they does not add measurable input lag

Thanks so much for doing these tests! Would be interesting to see more mice added to the list but I know that would be pricey.

Some CS:GO SLI/VSync Input lag tests

https://www.youtube.com/watch?v=NpQPzg8yq4w&a...87BHzftC6A

Pretty much same results as mine, he got 8ms more because of 143FPS and 125Hz mouse

still interested in seeing if windows XP has lower input lag like everyone says

as well as the WMO

no win xp does not have lower input lag thats for sure. WMO is still in its way to me, but I found other tests, its 22ms for mouse1 and 15ms start motion according to those.

Requesting steelseries kinzu v3.
http://steelseries.com/products/mice/steelseries-kinzu-v3
Where I can donate?

added keyboard results

Also, I was impressed by build quality of PCB of Corsair. On the other hand Razer has low quality dirty PCB with poor components soldering. Tesoro is somewhere in the middle - PCB is dirty but build quality of PCB and components mounting is good.

Thank you for the excellent tests!

Are you able to discern who the OEM is for the K65? I instantly tossed my BlackWidow Ultimate Tournament into its box and to the graveyard corner of my closet once I came across your findings! :( I am back to my trusty CM QuickFire Stealth which is manufactured by Costar. It is nearly identical to Filco's tenkeyless models in design: same OEM, same PCB layout, same controller, just slightly cheaper materials and workmanship to cut costs. As far as I can tell, Costar-produced keyboards all seem to be pretty close to each other in terms of quality. They seem to be a solid OEM.

Tear-down and comparison of a Filco and QuickFire Rapid, for the interested:

http://www.youtube.com/watch?v=Cy1JgF4_UT0

My initial assumption is that as long as you're running a mechanical produced by a reputable OEM like Costar or Ducky, you should be in good territory in terms of latency. My assumption is that programming keyboard controllers shouldn't be anywhere near as complicated as programming an optical mouse controller, as long as you're not trying to add all sorts of crazy macro and function-layer features (and even then...) But I guess these are merely assumptions. I would love to see you run more keyboard tests! Though I understand the risk of purchasing a $130+ high-end mechanical like a Ducky just to disassemble it and void the warranty is not exactly small.

Razer gets the ultimate shake of the head in all of this. Before the Tournament editions came out, they got a lot of flack from the mechanical keyboard community for changing the switches in their products from Cherry MXs to Chinese knock-off Kaihuas to cut costs, but DID NOT pass this savings on to the consumer. Now they have their proprietary switches (also produced by Kaihua,) but it looks like they cut corners even further in their production chain. Count me as another shmuck who fell victim to Razer marketing! I WILL say that the lower actuation distance on their proprietary switches CAN feel subjectively nicer than a typical Cherry switch, but if this also comes at the cost of extremely shoddy workmanship that ultimately results in ADDED LATENCY, then what's the fucking point? No serious gamer should use Razer mechanical keyboards! The results of your latency tests speak for themselves!

keyboards ran at 125hz?

1kHz. Will be 4ms more on average for 125Hz

did you try a ps/2 cable/converter? should be better than USB.

i'm interested in this too.

if it is "converter" it won't be better since it will convert USB anyways, most likely it will add its own delay on top of USB latency. As for adaptors, that come with keyboard, they do not make any difference either, I tried. Also take a note, that in theory using PS/2 should give you 1ms advantage at maximum over 1000Hz USB, so not much difference even if it exists.

How did you know that?

KB polling rate for each data pipe of the device can be checked with software like this http://k0lee.com/dc3000/usbts.htm.
bInterval in Endpoint Descriptor is what you are looking for. This is maximum polling interval in milliseconds for this data pipe

Endpoint Descriptor:
bEndpointAddress: 0x81
Transfer Type: Interrupt
wMaxPacketSize: 0x0008 (8)
bInterval: 0x01 (1) <<<<<<<<<<<<<<<<<<

As for 125Hz vs 1000Hz:
If device is running at 125Hz it's interrupt data is guaranteed to be delivered within 8ms after it generated interrupt flag on USB. It can be lower than 8ms, but its random, depending on what is happeing in USB subsystem. Hence 125Hz device not necesserily adds 8ms lag on each separate interrupt, but it will certainly add few ms compared to 500Hz/1000Hz device. In practice it is simple random between 0.5ms and 9ms with average of 4 to 6ms depending on your luck. Easy to see with bloody mouse bump test if you have 2 identical mice one on 125Hz other on 500/1000Hz

Thanks for the info!
My info from SteelSeries6Gv2 http://pastebin.com/s0fTuHt0
By spending hour googling looks like it's USB 1.1 Low-speed device with 10ms polling interval.
That's why SteelSeries recommends using PS/2.

ctrl+f "USB OR PS/2?" at
http://steelseries.com/products/keyboards/steelseries-6gv2
"...any polling rate above 200Hz is simply a waste of CPU time and really just a result of pointless marketing hype..."
:>

Now it sounds more like "We decide to produce keyboards cheaper by using old'n'cheap components like USB 1.1 Low-speed controller that allows using USB->PS/2 adapter. Cheaper production more PROFIT".

Well, modern HIDs these days use USB 1.1 spec at full speed (12Mbps). The reason for this is that you can not set binterval for interrupts lower than 8ms for low speed USB devices iirc. Also to benefit from using ps/2 over 125Hz default USB you need to manually over clock the said port, because it is 100Hz max by default.
I once used steel series KB - returned it next day, because it seemed laggy as hell. Back then I thought that it was due poor switches, but now I see, that they just do not know how to write proper USB software lol

You can overclock mouse at PS/2 but not a keyboard. PS/2 keyboard acts in other way than PS/2 mouse.

That makes PS/2 even more useless nowadays

You got it wrong :(

i thought ps2 port for keyboards was interrupt-based? meaning that it doesnt poll? or did i misunderstand yr comments?

From the point of view of the CPU, an USB device actually looks the same, looks like it is "interrupt based". The polling is happening between the USB host controller and the device. The controller does that everything about that by itself. The polling is completely hidden from the CPU.

When the USB host controller managed to get new data from a device, it will signal an interrupt. The CPU can then immediately start reading actual data. There's no waiting involved on the CPU, completely not what you might imagine if you hear that USB is "polling based".

Where are the G502 test results?

do not have mouse yet, and I do not think I will actually test it, since this one http://cdn.overclock.net/e/e7/e7b441c1_respon...140907.png is actually covering it all, so you can simply compre to my G100s results and calculate overall input lag from that.

Also that rafa test is far more accurate then mine in terms of relative mouse button lag. As his accuracy is <0.1ms, while mine is 1ms by default because camera is 1000FPS and I have to deal with some random factors like input event relative to engine frame and monitor frame which adds at least another 1ms for low amount of measuremenets (<20).

P.S. Dig into his blog, you will find alot of indepth tests for G502, like oscillograms of its output speed vs time etc. I do not think I have time and motivation to do such things.

Awesome, thx for the info. Looking now....

I'm gonna get one of those with a negative response time. Shoot before I click!

this chart is relative to G300 hence mice with negative response times are simply faster than G300 by that amount, no time warping there :D

Thanks :)

I don't know anything about the sensors used in mice but would it be possible to test the delay by controlling the sensor's illumination led itself? One could make an easy circuit with a battery, a resistor and a switch and measure the delay between led illumination and changing frame. Keep the mouse in movement, toggle the led on, measure.

One step further would be to make a test with Arduino/RPi. Control the illumination led with the chip and measure the delay between the led illumination and first movement data arrival.

This is speculation only and I've probably missed something because no one has conducted these tests.

thing is, sensor ICs are dynamically controlling this led, hence if you interrupt that back control loop mouse will not be functioning correctly therefor we will not be able to rely on results. Also that dynamic led current control is crucial as it is what allows mouse to adjust to different pads without any tweaking in software by user.

I don't understand why you test CS:GO at 250 FPS when using 144Hz?

As far as I know FPS should equal:

a) Hz + (6 to 8)
b) Hz * 2 + (6 to 8)
c) Hz * 3 + (6 to 8)

etc..

Otherwise you will get micro stutters or tearing. And your input results would not be measurable or comparable.

So if you are using 144 Hz, you should either try max fps 150-152 or 294-296.

250 FPS is good for 120Hz.

emm why so? With Vsync off it does not matter what fps you put it will not be in sync with hz of monitor anyways. More FPS -> less input lag, more Hz -> less input lag, as simple as that. You are probably not aware of that GPU output buffer is swapped as soon as new frame is ready while Vsync off therefore you can have more than one game frame per monitor refresh. Tears do not have anything to do with these results and the higher are FPS value the less noticeable they are since you get more frames per refresh and hence less pixel shift in each tear line. Regarding microstutter I do not see where it will come from...

That is not true, it is a known fact, not only I have seen my self with the CRTs and my BenQ xl2411z LCD but it has been discussed over here:

http://www.blurbusters.com/gsync/how-does-gsync-fix-stutters/

Check the graphs give it a good read.

V S Y N C O F F
S
Y
N
C
O
F
F


forgot to mention it in main post though

noacc that also applies to when VSYNC is off ofcourse

Nope. With vsync/gsync screen is displaying only one frame per display refresh, so if next frame is not complete in time then previous one is held for another refresh period of the monitor, therefore you get stutter and enormous input lag if fps=\=hz. Gsync fixes this issue by introducing variable monitor refresh rate, which allow to compensate for frame rate drops. Vsync off is completely different matter. Display is constantly reading output buffer of gpu regardless of anything. Gpu is constantly updating its output buffer regardless of anything too. They are not in sync and do not depend on each other. So putting some 'proper' fps value is useless.

I have v-sync off and always had it off. I just did visual tests and I can see with my own eyes that setting fps to a different range for example 120 Hz * 2 + 60 results in micro stutter and can easily be noticed when moving the mouse in circles. But when setting it to 120 Hz * 2 + 10 the motion is buttery smooth. So go figure. Tested in CS:GO. I don't have a 1000 fps camera to prove it but it can be seen with the naked eye.

how exactly you define miro stutter? And what exactly are you registering with yor eyes? And where did you get those strange equations *2+10 etc? What monitor are you using, what GPU are you using? If it possible make screenshot with GPU settings and ingame screenshot with gfx settings.

I do not see any "microstutters" neither I do expiriency any significant tearing in both CS and QL, neither at 120Hz nor at 144Hz with FPS cap > Hz. What I see is progressively less lag. less tearing, smoother motion and panning with increase of FPS cap without any steps and thresholds whatsoever.

Also take a note, that all my measurements are well backed up with other people experiments and are well inline with theoretical lag estimation, so I still do not see how my "input results would not be measurable or comparable.". They are very comperable because I did those with exact same settings of FPS/Hz/Vsync. They would be perfectly fine even if I used Vsync=on, but there is no point, since everybody play with Vsync=off anyway.

And I still do not see any theoretical or experimental back up for this statement
"So if you are using 144 Hz, you should either try max fps 150-152 or 294-296."

he sees more microstutter because the tear lines move around more at 120 Hz * 2 + 60=300 than at 120 Hz * 2 + 10=250

and also csgo framerate is more stable with fps_max 250 than fps_max 300

regardless, with vsync off, the fps cap should only affect input lag in that higher fps results in less lag.

[+]Error: The target user can't receive judgements

that is what I suspect too to be the source of his believes that he has less "microstutters" with said settings

can it also be linked to the very basic default monitor settings (Hz wise?) I am sure that some resolutions and HZ have a better response time than others? So perhaps his Hz is not set to the monitors best settings?

I am sure that some resolutions and HZ have a better response time than others?

That is caused by special aspects of human perception. We tend to treat smoother image as more responsive, just like we confuse higher sensitivity of the mouse as more responsive if we are not aware of sensitivity change.
I will stress it another time that objective experimental data clearly shows, that for Vsync=OFF more FPS => less input lag. Always. Without any dependance on monitor refresh rate. Furthermore simple common sense is enough to understand the basis for this effect. As input handled once per frame before each frame, the less time it take to calculate and render it, the smaller is lag.
Also do not forget, that you are not going to actually reliably destinuish between 200FPS cap input lag and 300FPS cap input lag as it is less than 1ms difference, however smootheness is clearly distinguishable with naked eye. So all those Hz/FPS talks based on "feel" are nothing more than confusing input lag with smoothness. Sure there are some "bad" ratios like 120Hz/240FPS, where you most likely will get semi stationary tearing lines which will be more noticeable than when you use 120Hz/200FPS or even 125FPS. But as long as your Hz and FPS cap are not divisible you should be fine.

Yeah I never use vscync, and that's really useful re the fps thing / hz ratio. I only sort of mentioned the hz and ms response time as it seems confusing, as when I do a system performance test in bf4 it actually tells me the ms response time. When I scale the resolution and settings down, the the ms response time goes down. I wonder if that might be to do with the [per frame before each frame] thing, or a nvidia setting changed, or just monitor handling the hz better, for the new settings / resolution!

monitor is handling everything exactly the same regardless of what game is rendering. When you scale everything down and your "response" goes lower that basically means you get higher fps value.

Try put this in console PerfOverlay.DrawGraph 1. It will give you CPU and GPU frame times. What you want to acheive with your settings is that your GPU frame times never exceed CPU frame times otherwise your effective FPS on monitor are less than what FRAPS is showing.

As I see alot of people are confusing what is going on in game engine, GPU and monitor I was thinking of creating short animation video which will explain in simplified manner the very basis of such things, I think it will be far more understandable than my WOTs.

If you have some video editing/animation skills we could collaborate on this.

omg this could be the source of the problems I have with bf4, Thx, Although I have also always wondered what is better for the input with 64bit or 32bit.

I have Fraps, and can convert. As for the animations / editing etc I have not really touched on for years, but I am sure I could do something, depends on what you have in mind.

with BF4 go 64bit always because this game is actually utilkising it. Also when changing setting always restart bf4 because it is not updating them properly on the fly.

Here is simplified picture that I posted elswehere explaining exact same case when GPU time > CPU time.

ahh Ok.

I think I will do a fresh install of the game, and only touch the 64bit. And restart it when settings arte changed, and see what happens. Is there a way to record a demo and timedemo function in bf4, like there was in Q4 etc?

you can do it with ingame console and there were some tools on overclock.net that could help you visualize the results without messing with excel. Just google it somthing like BF4 frametime benchmark.

If you only need CPU framtimes FRAPS/FRAFS are good things.

And you do not need to reinstall iirc. It installs both executables by default.

ok thx, have done that. didn't reinstall. Do you have any example "ideal situation" graphs of this. As I found that I had a number of different ones. One where the CPU was quite straight lined, with GPU not going over it, until it had with occasional spikes, and another graph where the CPU and GPU were going rapidly in connection together, like a rocky mountain profile. I had a 0.06 ms input on one of them, so that was not great. So will have to fix that part, however if you have any good graph combinations then that would be nice to see.

it really depends on what is your average FPS in actual firefights. Make 2 screenshots one on 64p populated server siege of shanghai on th skyscrapper looking down and another one on test range explode barrels near heli parking and do screenshot right after so we can see how far your FPS drops. Post both screens here or pm me.

thx will do. I have done quite a few runs at different fps and hz and resolutions etc. updating the bf4 thread.

Well if the statement by the user below is true about tear lines moving around more at Hz*2+Hz/2 Rather than Hz*2+ a number like 6 or 8 or 10 wouldn't that mean that micro stuttering is the result of those tear lines moving around more?

It won't help speaking about monitor issues because I tested this effect 5 years ago too on a 100Hz CRT and now I have the BenQ xl2411z which also displays the same problem at the above mentioned FPS cap.

My frame rates during the test are stable to the cap meaning when I move my mouse in circles to detect the micro stuttering or the tears moving around, my frame rate doesn't drop below the cap.

Now of course stuttering and tears moving around are two different things... Stuttering can cause problems with the latency tests while tears moving around simply effects the visual side so your results may as well be viewed as accurate if that is the case.

I guess stuttering and micro stuttering are two different things. Lets refer micro stuttering as the visual effect of tears moving around the screen at a point when it becomes noticeable.

If you still don't notice the visual micro stutter at those fps caps which I mentioned it's weird.

I am now on GTX 670 with mostly default settings in nvidia control panel and vsync turned off in game.

What can you say about multicore rendering option? How does it affect the experience in CS GO?

disable multicore rendering if you still get 200+FPS without it.

Record a benchmark with FRAPS and post here your frametimes csv file. one minute of moving your mouse and running around is enough. I still suspect that you have some kind of performance issues more than anything. Offline, no bots and post the map which you were using so I can compare it with my results.

And I suggest we move away from your stutter definition because it is confusing. The stutter and microstutter is the effect of irregular gap between the states of equable moving object or equable panning screen. Those can affect your performance because you get false information about ingame environment. On the contrary tearing is visual inconvenience only.

Another thing to try - check your issues with 800x600 resolution. If they are gone that is 99% for the tearing lines that makes you feel uncomfortable at certain refresh rates. I had this kind of feel too that was partly the reason why I even bother with input lag measurements etc.

And again what ratios are you having the most problems with? I will try to reproduce the issue and film it.

What mouse are you using?

EDIT: Meanwhile I made bench for CSGO at 250FPS with this settings
and I got the following results

As I am not CS player and I am not use to the game I do not feel those frame variations asmuch, but tears are more noticable than in QL. Not sure if this frametime variations are actually the source of inconvinience for you, looking foirward to see your benchs.

Attached Image: 103194-cs_settings1.png (2278KB)

Ok well here are the tests all at 120Hz.

120 FPS max was buttery smooth while 180 was bad.
240 FPS max was buttery smooth while 300 was bad.
360 FPS max was buttery smooth.

Attached Misc File: 103226-120.csv (65KB)

Attached Misc File: 103227-180.csv (97KB)

Attached Misc File: 103229-300.csv (162KB)

Attached Misc File: 103230-360.csv (194KB)

Attached Misc File: 103231-240.csv (130KB)

And frame time files?

added to that post.

checked those, performance shouldn't be the source of the issue you having. What about lower res? Is it better than 1080p on same Hz?

Well it was always like that, even in source and I had a crt back then at lower resolutions with a totally different hardware set :) I am convinced counterstrike games are generally not as stable shooters and meant for general public and having the best mouse and monitor settings is not as important there as the whole thing is too random. I would call cs a tactical shooter with tactics being the key to victory be it 1v1 tactics or team tactics, not a hardcore shooter. Not sure about how Team Fortress plays. UT and Quake are much more stable in regards to point and shoot gameplay from my own experience.

well I'd say having best hw setup is just giving more pleasure from the game. While player's performance does not depend on this THAT much how hw companies would like to show. Because all those mumbo jumbos with input lag, hz and fpss translates into couple percent higher acc on average I believe, which is not game deciding factor usually. I was watching latest QL Moscow lan party and by the end of it ppl actually adapted to those 75Hz monitors there and their raw aim was almost the same as when they played at home.

However from my own experience learning process on very good low latency setup is noticeably faster.

i should so be asleep by now (been up al night, so if i'm not reading this correctly, ignore me), but he is specifically talking of screen tearing, not anything to do with lag at all (even if he doesn't know the right term). This is just sync issues with the frames + refresh rate, in fact, i'm sure i don't have to even explain this to you.

These effects do happen in some scenarios, i'm not sure of his exactly, but running 120hz with 120-130fps vs double the frame rate has huge impacts on screen tearing. Maybe it does go even further and having odd numbers (120hz, but 300fps, adds in another variance of tearing again - i have no idea.

right you are

Would it be possible for you to test how much laggier m_rawinput 1 is in CSGO compared to it turned off ?

I got a pretty low sens and having it off and doing a quick 360 turn, it honestly feels 2 to 3 times more responsive

Maybe that's because in that case your mouse may be reporting only 125hz and so the sensitivity jumps up, hence the feeling it is more responsive?

yea i will maybe this weekend. Meanwhile measure cm/360 with both inputs as well as ingame accel with both inputs. I suspect that you experiencing slightly different sens or maybe a bit of accel.

noacc can you somehow check if rawinput bypasses hidusbf driver? meaning in case of rawinput the mx518 defaults to 125Hz?

No it shouldn't and it does not. I tried to install quake live mouse accel moufltr and it works properly with raw input. Afaik any application is reading from HID driver anyway, that's the lowest hw abstraction level. If application needs to go deeper it will have to have its own driver to replace original windows driver like mouse software do.
moufltr for quake live style accel at driver level - http://accel.drok-radnik.com/

so raw is not really raw then, at driver and registry level, if I am reading this right?

this little wot below will clear it all up for you
The raw input model is different from the original Windows input model for the keyboard and mouse. In the original input model, an application receives device-independent input in the form of messages that are sent or posted to its windows, such as WM_CHAR, WM_MOUSEMOVE, and WM_APPCOMMAND. In contrast, for raw input an application must register the devices it wants to get data from. Also, the application gets the raw input through the WM_INPUT message.
There are several advantages to the raw input model:
An application does not have to detect or open the input device.
An application gets the data directly from the device, and processes the data for its needs.
An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices.
An application manages the data traffic by specifying data from a collection of devices or only specific device types.
HID devices can be used as they become available in the marketplace, without waiting for new message types or an updated OS to have new commands in WM_APPCOMMAND.

source