Blur Busters Forums

Hi,
i have a theoretical question and maybe a new research-topic:

I am currently playing with a 1000Hz Mouse, 120Hz Lightboost and a frame-cap in BF3 of 121 fps.
In CSGO I left my fps uncapped [getting around 300-600].

Now my consideration: Wouldn't it be better to set my refresh-rate to 125Hz and cap my fps to for example 250? This would sync the monitor and my fps with my mouse's refresh-rate and all would have the common divisor of 125.

I made a crappy illustration in PowerPoint:


Please don't answer something like: "Lightboost is better than 125Hz" ^^ . This is just a theoretical consideration and maybe an idea for all ULMB/Lightboost-modes with custom refresh-rates.

So: Would these settings positively affect Input-lag? I know these settings loose more and more value the higher the uncapped fps are going. Is there a fixed amount of fps by which these techniques are becoming unreasonable or to be precise: Is this whole consideration right and rational?

I will curiously waiting for answers.

TheLeetFly wrote:Now my consideration: Wouldn't it be better to set my refresh-rate to 125Hz and cap my fps to for example 250? This would sync the monitor and my fps with my mouse's refresh-rate and all would have the common divisor of 125.

That won't be perfect because often 125Hz is often 125.02317Hz or 125.0095Hz or 119.9918Hz etc. You can see it when you load ToastyX or NVIDIA Custom Resolution -- the refresh rate is almost never exact, it's off by a tiny bit. And the 250fps cap may actually vary between 249-251fps. So there's no perfect sync. It may actually hurt input lag, because of the difference. e.g. 125.1Hz harmonic frequency with 250Hz is an 0.1Hz harmonic. That means, every 10 seconds, you will suddenly jump to the "next tick" upwards or downwards, and the attendant microstutter and/or input lag sudden change. i.e. your input lag will be slowly slewing upwards/downwards over a 10 second period during a 0.1Hz harmonic, and then suddenly 'reset' back, before slowly slewing. Most people won't notice, but competitive gamers may. It's best to use a framerate cap that developers higher-frequency harmonics rather than low-frequency harmonics, e.g. fps_max 300 during 144Hz often feels better.

On the other hand, there's the visual quality considerations. If that's more important than input lag, visual quality is often better when framerate is perfectly synchronized with refreshrate (ala framerate-maximized VSYNC ON with no framerate drops). But competitive gamers will tend to not do that, since that adds input lag in exchange for lack of microstutter (during situation of overkill GPU on older games, where you can maintain max-rate VSYNC ON).

If you're running source engine games on modern systems that runs triple-digit framerates, it is best to just leave framerate uncapped or if you want a cap, then cap at high numbers (300 or 500) for minimum input lag. Input lag caused by GPU is the frame render time, so running at 500fps (on a single card non-SLI system) will reduce GPU-share of input lag to 1/500th second, so the higher the framerate, the lower the input lag the GPU gives you.

There are exceptions. The exception is when the videogame (e.g. Quake Live) is intentionally automatically refreshing based on the mouse poll timing, but the vast majority of video games don't synchronize the timing of frame generation to the mouse poll. Quake Live uses a 125 or 250 framerate limit because it is synchronized to the mouse poll. But setting fps_max 250 does not do perfect sync to the mouse polls in source engine games.

Also:
Three-way *perfect* synchronization between mouse poll rate, refresh rate, and frame rate, has historically never been done before GSYNC. With the arrival of GSYNC, it's now finally technologically possible to have 3-way sync between all Hz (mouse Hz, refresh Hz, and framerate) but I am not sure if any game has actually successfully done this, yet.

wouldn't quake live at 125fps on a gsync display achieve that?
or do you mean that quake live just uses 125 and 250 fps because those are factors of normal mouse polling rates?

from a bit of playing with mouse testing programs, it seems that mouse polling is not completely regular; my 500hz g100s sends consecutive updates 1ms apart sometimes on certain surfaces.

flood wrote:wouldn't quake live at 125fps on a gsync display achieve that?

Yes, theoretically it is already a perfect 3-way synchronization in that particular game, if the game is indeed synchronizing properly to mouse poll timings during GSYNC mode. Though, most seem to play Quake Live at 250fps now, rather than at 125fps, and the GSYNC limit is 144fps. If you configure to a 125fps limit, you may actually have a perfect 3-way sync (refreshrate & framerate synchronized to mouse poll rate).

flood wrote:from a bit of playing with mouse testing programs, it seems that mouse polling is not completely regular; my 500hz g100s sends consecutive updates 1ms apart sometimes on certain surfaces.

That's also a consideration as well, though GSYNC allows varying intervals frames (refreshes), so GSYNC would simply gracefully synchronize to those irregular timings on the fly.

I usually set my FPS cap to 240 in Source games. When it's set to 120 either manually or with Vsync, moving and looking around with the arrow keys feels smooth, but mouse movement feels choppy and lower than 120 updates per second. At 240 FPS, the mouse feels smooth while still keeping the screen tears stable (personal preference). Most other games have smooth mouse motion with Vsync turned on.
So why is the mouse not smooth in Source games at 120 FPS?

^what refresh rate are you running at? 120?

it should be smooth so long as the mouse is on the same side of the tear line

Monitor is at 120Hz, and the mouse polling rate doesn't seem to have an effect on the choppy motion when capping to 120 FPS.
I can of course easily maintain 240 FPS, but my laptop is another story.