Page 1 of 1
Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 17:45
by thanossapiens
Hi everyone
I'm trying to have as little lag as possible on my plain 60hz monitor(no extra features like freesync, etc)
It's a Dell U2515H and my gpu is GTX1650super.
Is this method still a decent one?
I saw that there is also the possibility of scanline sync but this seems more hassle free and I also just couldn't get scanline sync to work with all games.
https://blurbusters.com/howto-low-lag-vsync-on/
Thanks for your time
Re: Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 17:59
by jorimt
thanossapiens wrote: ↑04 May 2022, 17:45
Is this method still a decent one?
For standalone V-SYNC, it's pretty much that or Scanline Sync in this context, the RTSS decimal-level limiting method being the most hassle-free, as you mentioned.
For any lower tear-free latency you'll need VRR (which granted, you don't have currently).
Re: Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 18:03
by thanossapiens
jorimt wrote: ↑04 May 2022, 17:59
thanossapiens wrote: ↑04 May 2022, 17:45
Is this method still a decent one?
For standalone V-SYNC, it's pretty much that or Scanline Sync in this context, the RTSS decimal-level limiting method being the most hassle-free, as you mentioned.
For any lower tear-free latency you'll need VRR (which granted, you don't have currently).
Is there a reason it needs to be 0.01 and not 0.1+, just to be sure?
When I go to the website that measures the refresh rate it usually fluctuates a tiny bit, I just want to 100% be sure at all times that I have "low lag"
Re: Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 18:12
by Chief Blur Buster
thanossapiens wrote: ↑04 May 2022, 18:03
jorimt wrote: ↑04 May 2022, 17:59
thanossapiens wrote: ↑04 May 2022, 17:45
Is this method still a decent one?
For standalone V-SYNC, it's pretty much that or Scanline Sync in this context, the RTSS decimal-level limiting method being the most hassle-free, as you mentioned.
For any lower tear-free latency you'll need VRR (which granted, you don't have currently).
Is there a reason it needs to be 0.01 and not 0.1+, just to be sure?
When I go to the website that measures the refresh rate it usually fluctuates a tiny bit, I just want to 100% be sure at all times that I have "low lag"
For Low-Lag VSYNC HOWTO method:
It's actually system-specific
Some systems fluctuates less.
Other systems fluctuate more.
If your system fluctuates a lot, use a bigger margin (e.g. 0.1)
If your system is super-precise, use a tighter margin (e.g. 0.001)
However, it's not a hard-and-fast rule of thumb. There are other side effects (e.g. CPU clock precision varies too, not just GPU clock precision), so try a 0.01 difference, and see if it works. Motion could get worse if you get too tight or too loose. You can step up and down in approximately doublings or halvings (e.g. 0.01 -> 0.02 -> 0.05 -> 0.1) and see if lag or motion gets better/worse. But the easiest boilerplate recommendation for non-scanline-based low-lag VSYNC method for non-VRR displays was the 0.01 differential.
Other people use a more complex RTSS Scanline Sync or Special K Latent Sync to achieve the perfect 0 difference at low lag (the lowest lag method of perfect framerate=Hz on a fixed-Hz display). However, this technique is somewhat harder than the low-lag VSYNC HOWTO.
Re: Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 18:25
by thanossapiens
Chief Blur Buster wrote: ↑04 May 2022, 18:12
thanossapiens wrote: ↑04 May 2022, 18:03
jorimt wrote: ↑04 May 2022, 17:59
thanossapiens wrote: ↑04 May 2022, 17:45
Is this method still a decent one?
For standalone V-SYNC, it's pretty much that or Scanline Sync in this context, the RTSS decimal-level limiting method being the most hassle-free, as you mentioned.
For any lower tear-free latency you'll need VRR (which granted, you don't have currently).
Is there a reason it needs to be 0.01 and not 0.1+, just to be sure?
When I go to the website that measures the refresh rate it usually fluctuates a tiny bit, I just want to 100% be sure at all times that I have "low lag"
For Low-Lag VSYNC HOWTO method:
It's actually system-specific
Some systems fluctuates less.
Other systems fluctuate more.
If your system fluctuates a lot, use a bigger margin (e.g. 0.1)
If your system is super-precise, use a tighter margin (e.g. 0.001)
However, it's not a hard-and-fast rule of thumb. There are other side effects (e.g. CPU clock precision varies too, not just GPU clock precision), so try a 0.01 difference, and see if it works. Motion could get worse if you get too tight or too loose. You can step up and down in approximately doublings or halvings (e.g. 0.01 -> 0.02 -> 0.05 -> 0.1) and see if lag or motion gets better/worse. But the easiest boilerplate recommendation for non-scanline-based low-lag VSYNC method for non-VRR displays was the 0.01 differential.
Other people use a more complex RTSS Scanline Sync or Special K Latent Sync to achieve the perfect 0 difference at low lag (the lowest lag method of perfect framerate=Hz on a fixed-Hz display). However, this technique is somewhat harder than the low-lag VSYNC HOWTO.
Thanks for your answer.
Are there any statistics about the difference of framecap vs scanline sync?
My goal is to actually use this with a (pretty damn old by this point) plasma TV I got. I found that for my needs it's actually the best regardless of price; the black levels are slightly worse than OLED, but the motion clarity is way better, I couldn't believe how smooth it was. The only issue is that gaming TVs weren't a thing back then so they have quit more input lag, and it is ever so slightly noticeable.
It's not when I turn VSync Off though, it feels very responsive but the tearing is distracting, so I searched for remedies and these are the ones I found. If there are any besides RTSS and getting controller/keyboards with less lag please let me know.
Re: Lowering input lag with the RTSS frame cap method
Posted: 04 May 2022, 18:39
by Chief Blur Buster
thanossapiens wrote: ↑04 May 2022, 18:25
Thanks for your answer.
Are there any statistics about the difference of framecap vs scanline sync?
A few years ago someone compared all the methods of framerate=Hz (almost all possible alternatives to VSYNC ON) and found that the scanline sync methods sometimes had lower average lag than the low lag VSYNC HOWTO, and that the latency was more consistent (more unchanging). But it was subtle/minor.
I can't remember which thread it was, but maybe another forum user can find it?
Or perhaps it was one of those Battle(non)sense YouTube videos.
jorimt wrote: ↑04 May 2022, 17:59
For any lower tear-free latency you'll need VRR (which granted, you don't have currently).
Depending on the display, and using an AMD Radeon, it's possible to trick a non-VRR display into accepting a VRR signal. Then as long as the framepacing is perfect, the display keeps working. Some non-VRR displays was able to be tricked to VRR via a ToastyX force-FreeSync trick (works only on Radeons), but have a tight refresh rate range (e.g. 55-61Hz), but that would be sufficient enough range for framerate capping purposes.
However, these tests were done on very old LCDs a long ago.
Probably not worth the try, but I thought I'd add some very old knowledge.
Re: Lowering input lag with the RTSS frame cap method
Posted: 05 May 2022, 14:49
by thanossapiens
By the way, why doesn't the framecap work with VSYNC Off?
When I have it off I don't get tearing if my framerate is below 60, shouldn't this create a similar effect?