- Joined
- May 5, 2006
- Messages
- 5,913
I know not everyone is cut throat about a missed shot or being outdrawn gunshot timing wise in an online game every so often, but for a sense of completion I did a little more homework on that topic, since people bring up very competitive players who play simple to render games at 300fps to 500fps.
There is more to it, about running 300 to 500 fps on competitive games.
TLDR: 165hz still gives you advantage if running some easy to render competitive game at 300 - 500fps, in making sure you can react on the most current tick without missing it. The con is that it will show tearing as g-sync/v-sync are not active to cut that off to ~ 160fps in that scenario, where if you were running 300fps on a 360hz screen, or 500fps on a 500Hz+ screen, you wouldn't get tearing because you wouldn't be exceeding the peak Hz of the screen.
===========================================
. .
The 72ms minimum temporal gap on 128 tick servers , vs running extreme frame rate:
"
The 300 to 500 FPS advantage absolutely still happens on a 165Hz monitor:
Even though your monitor can only physically display 165 images per second, your game engine and your graphics card are working together much faster.
Why High FPS Helps on a 165Hz Monitor
.
The Subtick Exception (CS2)
If you are playing Counter-Strike 2, Valve’s subtick system operates slightly differently, but still rewards high FPS.
. .
Tearing
"The only downside to running 500 FPS on a 165Hz screen is screen tearing, which happens because the GPU is feeding the monitor multiple frames during a single refresh cycle. However, most competitive players gladly accept minor tearing in exchange for the massive drop in input lag and the advantage of landing on earlier server ticks. "
. .
Reflex Option
What you would suffer if you capped the 300 to 500fps rate in order to prevent tearing on a 165Hz screen :
Enabling G-Sync and Reflex caps to eliminate screen tearing increases your input latency by roughly 4.3 milliseconds and doubles your risk of a missed server tick entry.
Here is the exact breakdown of the delays and tick penalties you suffer when dropping from 500 FPS uncapped to a ~158 FPS cap on a 165Hz screen.
1. The Input Latency Penalty (+4.33ms)
Input latency is the time between physical mouse movement and the game engine processing that movement.
2. Missed Server Tick Entries (The Registration Delay)
Online servers look for player data at fixed intervals called "ticks."
500 FPS Engine: [2ms][2ms][2ms][2ms] <-- 4 chances to capture the absolute latest input
128-Tick Server: --------[7.81ms]--------
158 FPS Engine: [ 6.33ms ][ 6.33ms ] <-- Only 1 chance; input is older
Is the Harm Noticeable?
In high-stakes tactical shooters, this 4.3ms to 14ms variance is the difference between your bullet registering first or the enemy killing you around a corner.
There is more to it, about running 300 to 500 fps on competitive games.
TLDR: 165hz still gives you advantage if running some easy to render competitive game at 300 - 500fps, in making sure you can react on the most current tick without missing it. The con is that it will show tearing as g-sync/v-sync are not active to cut that off to ~ 160fps in that scenario, where if you were running 300fps on a 360hz screen, or 500fps on a 500Hz+ screen, you wouldn't get tearing because you wouldn't be exceeding the peak Hz of the screen.
===========================================
. .
The 72ms minimum temporal gap on 128 tick servers , vs running extreme frame rate:
. ."Even when running at 300 to 500 FPS, you are still playing inside a base ~72ms temporal gap caused by the combined forces of your network ping, server tick processing, and engine translation delays.
When you look at an enemy on your screen, you are not seeing where they are right now on the server; you are looking roughly 72ms into the past. However, generating new frames every 2 to 3 milliseconds remains highly advantageous because it optimizes how you interact with that specific 72ms window."
.
"Beating the 7.81ms Server Cutoff: When you click your mouse to shoot, your PC must package that input and send it to the server. If you run a flat 128 FPS, input sampling delays can add up to 7.81ms of extra local lag, potentially pushing your shot into a later server tick. At 500 FPS, that local lag drops to 2ms, giving your packet the speed it needs to slip into the earliest possible server tick "
.
"Impact on Server Time Rewinding (Lag Compensation)
When your shot packet finally arrives at the server, the server acknowledges the 72ms gap. It looks at your packet's exact timestamp, says "This player is playing 72ms in the past," and rewinds its simulation clock by exactly 72ms to see if your crosshair was on the enemy.
Because you were running at 500 FPS, the version of the past you reacted to was captured with absolute fidelity. The server rewinds its clock and finds that your ultra-fresh, 2ms-sampled input aligns perfectly with the historical record of the enemy's hitbox. Running high frame rates ensures that your local reality matches the server's authoritative rollback, giving you perfect hit registration despite the base 72ms delay.
Click to expand...
"
The 300 to 500 FPS advantage absolutely still happens on a 165Hz monitor:
Even though your monitor can only physically display 165 images per second, your game engine and your graphics card are working together much faster.
Why High FPS Helps on a 165Hz Monitor
- Input lag drops drastically: Your mouse inputs are tied to your framerate, not your monitor's refresh rate.
- Fresher frames for the display: At 500 FPS, your GPU renders 3 frames for every single 165Hz monitor refresh.
- Newest data wins: When the monitor is ready to show a new image, it grabs the most recently completed frame, reducing visual delay.
- Server packets stay fast: Your PC continues sending your actions to the server at that ultra-fast 2 to 3 millisecond pace
- (note: the server relationship to you still has a 72ms temporal gap due to the 128tick rate, the extreme fps just assures that your action will arrive on the "current" tick instead of missing one. Especially on very high Hz screen -> Anything you react to or aim at -after- the current tick lands, before the next tick does, will be operating on frames your local client is predicting/interpolating that do not necessarily correspond to the server's next tick/scene action state (aka: "the visual lie").
.
The Subtick Exception (CS2)
If you are playing Counter-Strike 2, Valve’s subtick system operates slightly differently, but still rewards high FPS.
- CS2 logs the exact millisecond of your click between ticks, regardless of framerate.
- However, higher FPS means the engine samples your mouse position more frequently.
- High FPS ensures your crosshair is physically on the enemy's hitbox at the exact millisecond the subtick registers.
. .
Tearing
"The only downside to running 500 FPS on a 165Hz screen is screen tearing, which happens because the GPU is feeding the monitor multiple frames during a single refresh cycle. However, most competitive players gladly accept minor tearing in exchange for the massive drop in input lag and the advantage of landing on earlier server ticks. "
. .
Reflex Option
.How Reflex Enhances the 500 FPS Server Advantage
When you run at 500 FPS, you want your mouse clicks sampled every 2ms so they can beat the 7.81ms server tick cutoff. Reflex ensures this happens perfectly via two main mechanisms:
The Ultimate Combined Timeline
- Eliminates Local "Input Stale Time": Without Reflex, your CPU might pull your mouse data and then let it sit in a rendering queue for 3ms before the GPU draws the frame. By the time that frame finishes and the packet is sent, your input is already "stale." Reflex forces the CPU to sample your mouse click at the absolute last microsecond before the GPU renders, making the timestamp sent to the server as fresh as possible.
- Flattens Frame Time Spikes (Jitter): On a 128-tick server, consistency is everything. If your frame times wildly bounce between 2ms and 6ms (frame jitter), your packets will arrive at irregular intervals, occasionally missing the server's tick cutoff. Reflex stabilizes frame pacing, ensuring a rock-solid 2ms heartbeat for your input pipeline.
When you combine 500 FPS + Reflex ON + 128-Tick Server, your pipeline operates at peak competitive efficiency:
1. [Physical Click] ──► Captured instantly by CPU (0ms queue delay thanks to Reflex)
2. [Local Frame] ──► Rendered in a crisp 2.0ms (500 FPS)
3. [Network Packet] ──► Dispatched immediately with a hyper-accurate timestamp
4. [Server Cutoff] ──► Easily beats the 7.81ms tick window due to zero local lag
5. [Time Rewind] ──► Server rewinds the 72ms base gap and finds perfect alignment
The Only Exception to Watch Out For
Reflex will only protect your 500 FPS advantage if you keep your framerate completely uncapped (or capped manually at a massive number like 500 in the game's console).
If you accidentally turn on G-Sync alongside Reflex without an uncapped setting, Reflex will automatically pull your framerate down to 158 FPS to match your 165Hz monitor. If that happens, your frame times drop from 2ms to 6.3ms, which will slightly degrade the ultra-fast server packet delivery advantage you are aiming for.
Click to expand...
-----------------------Proof from Tech Reviewers (The Latency Data)
Independent labs like Blur Busters and Tom's Hardware have benchmarked these exact scenarios using hardware latency analyzers. Their data proves that when you leave your FPS completely uncapped, turning Reflex ON drops total end-to-end system latency across the board compared to leaving Reflex OFF
What you would suffer if you capped the 300 to 500fps rate in order to prevent tearing on a 165Hz screen :
Enabling G-Sync and Reflex caps to eliminate screen tearing increases your input latency by roughly 4.3 milliseconds and doubles your risk of a missed server tick entry.
Here is the exact breakdown of the delays and tick penalties you suffer when dropping from 500 FPS uncapped to a ~158 FPS cap on a 165Hz screen.
1. The Input Latency Penalty (+4.33ms)
Input latency is the time between physical mouse movement and the game engine processing that movement.
- At 500 FPS Uncapped: The engine generates a frame every 2.00 milliseconds. Your input is never more than 2.00ms old when a frame is built.
- At 158 FPS Capped: The engine is slowed down to match your monitor, generating a frame every 6.33 milliseconds.
- The Harm: You add an automatic mathematical delay of 4.33ms to every single action you take before it even leaves your computer.
2. Missed Server Tick Entries (The Registration Delay)
Online servers look for player data at fixed intervals called "ticks."
- On a 128-Tick Server (Valorant, CS2 Premier): The server updates every 7.81 milliseconds.
- On a 64-Tick Server (Apex Legends, Matchmaking): The server updates every 15.62 milliseconds.
500 FPS Engine: [2ms][2ms][2ms][2ms] <-- 4 chances to capture the absolute latest input
128-Tick Server: --------[7.81ms]--------
158 FPS Engine: [ 6.33ms ][ 6.33ms ] <-- Only 1 chance; input is older
- The 500 FPS Advantage: At 2ms per frame, your PC inputs data roughly 4 times during a single 128-tick server cycle. The packet sent to the server contains an input that is practically brand new.
- The 158 FPS Penalty: At 6.33ms per frame, your PC only inputs data once per server tick. If your mouse click happens right after a frame is captured, it must wait nearly a full 6.33ms for the next frame, causing it to miss the current server tick entirely. Your action is delayed to the next packet, adding up to 14+ milliseconds of total delay before the server registers your shot.
Is the Harm Noticeable?
| Metric | 500 FPS Uncapped | 158 FPS Capped (No Tearing) | The Penalty |
|---|---|---|---|
| Frame Time / Local Input Lag | 2.00ms | 6.33ms | +4.33ms slower |
| Inputs Per 128-Tick Cycle | ~4 inputs | ~1 input | 3 missed optimization windows |
| Max Potential Server Delay | Very Low (High precision) | Moderate (Higher risk of desync) | Missed tick registration |
Last edited: