Hmm... if that is the case, then it might be that your drivers do some smart-ass handing of wglSwapIntervalEXT, pretending to the application that there's no vsync but using its own (buggy?) delay buffers. It would be video lag then, not input lag.
Or it could be an entirely different mechanism, wglSwapIntervalEXT somehow inducing input lag.
What's your in_mouse, sys_yieldcpu, sys_highpriority? Does flipping any of these help?

Well well, at least I beat the placebo machine 15-0 after I realized how to actually test it. Speedjumping around dm3 wasn't accurate enough because the human mind is so good at compensating and adjusting. I found that I could hit 100% placebo detection with simply trying to do quick flicking shots while jumping around, 90-180 degrees to certain places you are used to shooting, if it didn't feel natural / felt a bit off, then vsync was on

One of the problems with these kinds of testers is that at least I've tried quite a few settings on localhost vs bot that have yielded very impressive scores, but then going to server vs. real people in real games I've often times found big performance dips. One of the best examples was when I tried to run 160hz/308fps 800x600. It felt great but a bit heavy vs bot, but I was playing a lot worse on server, felt like I was behind on all shots and it was a lot worse than dinput Dinput you could adjust to quite quickly and might even forget it on.

Judging by games against bot, vsync + fix faired worse than normal settings, which should be no surprise, but the difference was not as big as I would have thought, so good work

Too bad I don't have my other lcd hooked up atm. to test it :/

The "laggish inresponsive" feeling i get with vid_vsync 1 can be compared to -dinput (in_mouse 2) a feeling that i dont like. Maby ppl who use in_mouse 2 dosnt feel the difference btw vid_vsync 0 and 1, as ppl with in_mouse 1 (more responsive mouse, when using xp noaccelfix and in_m_os_parameters 0 ofc) are used to this more precise mousesfeeling

I doubt thats its possible to get the same responsive feeling with vid_vsync 1 as with 0. Imo cl_independentphysics 1 and cl_maxfps 0 is good enough for any user (if you have a good setup). But IF it was possible, and its really nice you are trying tonik, to get se exakt same feeling with vid_vsync 1, then its great.

Does it matter what cl_maxfps value u use? For example if i use 100hz screen, should i use cl_maxfps 100 (probably not) or for example 150 (that is stable and above 100 hz) or even cl_maxfps 0 to get the most possible "rendering ahead effekt".

EDIT: Do i need to set sync to "application controled", instead of "force always off" in nvidia settings? To get rid of the laggy feeling? Cant try now, since im at work.

I´ve now tried some more and fooled around with different settings, as cl_maxfps, hz, sync on/off sys_ etc... Best result is when u use same fps as hz: for example 100hz/100fps (when using vid_vsync 1 ofc). Still the mouse feels laggy, and cant really tell if the cl_vsync_lag_fix 1 has any effect at all, feels like it adds nothing, still laggy feeling.

Im starting to guess this whole thing is "fake" ?

I've just checked that and did not get 60 FPS, it was only 50. Coincidentally I discovered that a task switch solves that and I get a steady 60 FPS. :p

Anyway, now I seem to have the same issues the other guys have. The visuals are really smooth but the mouse has that laggish feeling to it.

vid_vsync 1, no matter what maxfps, with or without the fix shows 0.1ms

vid_vsync 0:
maxfps 100 5.0ms
200 2.5ms
300 1.7ms
500+ 1.5ms

screen tears less at higher fps...

nVidia geForce 6600gt :/ LCD monitor at 75hz

I've really never felt vsync lag in ezQuake myself though I really can feel it in Quake3.. (mouse movements is like +50ping imho)

Tonik went underground?

Apparently people are getting mouse lag (in fact, video lag) with the nVidia drivers that use their own vsync+frame buffering algorithm. The problem seems to be related to the "Prerender limit" setting in the drivers, which defaults to 2, and lower values may be locked (which is the case for HangTime)

It is a sign of trouble if you get ~0.0 - 0.1 ms vidlag with vid_vsync 1 regardless of cl_vsync_lag_fix setting. Either don't use vid_vsync, or configure your drivers to do vsync the "traditional" way (nah, I don't know how to do that)

Ok. And how exactly do i get my drivers to "implement vsync properly"?

:-)

NVIDIA's pre-render limit value is an additional direct3d property and shouldn't affect OpenGL in any way.

(Emphasis on the word "shouldn't" as seeing how broken NVIDIA drivers have been the past year or so)

Yepp indead, prerender options is aviable with nvidia tweak for example, but only affects direct3d?

It may not be prerender limit after all, but there is something in NVidia drivers that buffers things up when the application requests vsync.

(If you're to believe HangTime: Yeah, with vid_vysnc 0 I get tearing sometimes if using e.g. 75hz 75fps. With vid_vsync 1 there is no noticeable tearing)

I looked into this last week.

Contrary to what has been stated above, there IS an OpenGL pre-render limit. I get the impression that people don't think it should be changed too low though since it's never been available in nvidia driver properties, and RivaTuner blocks you from setting it any lower than 2.

While searching around in registry, think I found the key which controls it: OGL_MaxFramesAllowed

By setting this to 1, I was able to get performance similar to that described by others:
-Vsync on, cl_vsync_lag_fix 0 = ~12ms vidlag
-Vsync on, cl_vsync_lag_fix 1 = ~4ms vidlag (adjusting the _tweak setting alters this value, but I haven't tested much with that due to Tonik's original post)

Oh, HangTime, now that's getting interesting.

What happens if you set OGL_MaxFramesAllowed to 0?

What is the lowest value you can get by tweaking _tweak?

Setting MaxFramesAllowed to 0 didn't seem to improve anything.
BUT, I've since discovered that this may have been because the first time I ran Quake after boot, vid_vsync 1 always gives 0.0ms vidlag (when using OGL_MFA 1). So I need to go back and test 0 again really.

Setting _tweak to 0 gives ~0.2ms vidlag.

Hah, this looks very promising! Tonik, is the linux patch coming any soon? BTW, if you do think that there's something "wrong" within the nvidia drivers, it might be beneficial for the guys working on nouveau if you explained them (then nouveau will get more interest from gamers and thus will get more hands to work on it).

Yeah this fix works but I noticed I move slower with this fix. I was bunnyhoppin around dm4 for few minutes and my ups were 20-30 lower than normal. I turned it off and I was insntantly moving faster. There was also some input lag as well not as bad as before but still there, I could feel it. I get 1.6ms at 308fps anyway so this isnt much of an improvement for me.

Faustov: I'll refrain from commenting on whether nvidia drivers are wrong, I don't have a clear picture from the reports here, and I haven't even bothered playing with the nvidia settings myself.

For now it seems that NVidia default handling of vsync may be suboptimal for high-fps games like QuakeWorld, while it probably works better for slower paced GPU hungry 3D shooters, that is, most new games, that's obviously the market NVidia is addressing.

bump!

what settings are the optimal (if any)?

Read this thread and see what works best for you

no news then thats what i wanted to know

I dont get any lag with vsync 1 in netquake, (not sh!t talking), but is there a relations to mouse rate and prediction /rate-ish ??!? Honestly this is a valid question.