Server Tick Rate Is Holding the Game Back

[Valence]

Animation delay, cast times, and effect resolutions are unrelated to the tick rate, odd as that may sound. Tick rate refers to how often the server updates your position (x,y coordinates), which is not the same as what you see on your screen (where you see yourself). In practice, the server can be up to 0.3s “behind” when a mechanic resolves. That small window can easily determine whether you’re considered inside or outside of an AoE marker, or whether you succeed or fail a mechanic.

As for sources, both XIVAlexander and ACT interact directly with FFXIV's network data. ACT, for example, sniffs network packets to record exact damage, healing, timestamps, etc. This is why eight people in the same raid will all generate identical logs. Analysis from both tools shows that while the server tick interval can fluctuate slightly, it consistently averages around 0.3 seconds. Regardless of whether the tick rate is exactly ~0.3s or not, the point is that its current speed is incapable of keeping up with the faster encounters introduced in Dawntrail.

I don't understand your reply and what you're trying to tell me. I know what a server tick is and I'm telling you it's probably not the root of the problem, but delays and processes are.
I don't know where you got your 0.3s from either?

I'd refer again to this thread that goes more in depth about it. Either way I do agree with you that all of this is a problem, and the position refresh rate doubly so.

[Umbrasin]

I’m glad to see so much discussion here. Reading responses, however, there's a lot of confusion about what server tick rate is and governs. I really should have defined it in my initial post. Here's some (hopefully) clear definitions that should help.

Positional Tick Rate: How often the server updates and confirms game state (e.g., your character’s exact x,y position, HoT/DoT ticks, debuff expirations).

The server checks your position roughly every 0.3 seconds. That means when a mechanic resolves, it may be judging your position based on data that’s up to ~0.3s old. This is why you can appear outside an AoE on your screen but still be registered inside by the server. Timing for HoTs and DoTs also align with tick rate: they tick every 3 seconds (10 × 0.3s).

Latency (Ping): The round-trip time for your client to send a packet to the server and get a response back. Latency is about the speed of your connection to the server, not how often the server itself updates.
Higher latency makes your inputs take longer to reach the server, and the server’s confirmations take longer to reach you. For example, if your ping is 100ms, it takes ~50ms for your action to reach the server and ~50ms to hear back. This can make mechanics feel delayed, but it’s distinct from tick rate (which is server-side sampling).

Animation Lock: A client-side restriction that prevents you from moving or using another action until an ability’s animation lock period ends.
Animation lock is a client-side restriction preventing movement or another action until an ability’s lock period ends (typically ~0.6s for GCDs, ~0.1–0.6s for oGCDs). High latency extends this lock because the client waits for server acknowledgment before releasing you, which is why higher-ping players feel stuck longer when weaving oGCDs.

Interaction with Latency: Animation lock compounds latency. The higher your ping, the longer your character remains stuck. This is why players in regions far from servers (e.g., EU players on NA data centers) complain most about rotational clunkiness and weaving.

Snapshot (mechanic resolution): When the server determines the outcome of an action at a fixed moment in time (when a cast bar finishes or when an AoE indicator disappears). Your position, buffs, and state are checked at that instant and not when the animation hits. Snapshots are design-driven and exist outside of tick rate, but the 0.3s tick interval + latency makes them feel harsher since the server may be resolving based on slightly outdated positional data.

Action Triggers (Ability/Spell Resolution): The internal timing system that governs when the server accepts and processes actions like spells, abilities, and GCD/oGCD usage.
These are NOT tied to the 0.3s positional tick rate. They’re on their own scheduling system that operates with much finer granularity (down to server frame timing, roughly tens of milliseconds). That’s why you can press an ability at any time and you’re not limited to 0.3s “windows” to cast a spell or ability.

What it Affects: Whether your input is recognized (as long as it reaches the server in time) and when the server puts it into the queue. This is why GCDs flow smoothly at 2.5s (or faster) without being forced into awkward 0.3s chunks.

[Umbrasin]

I don't understand your reply and what you're trying to tell me. I know what a server tick is and I'm telling you it's probably not the root of the problem, but delays and processes are.
I don't know where you got your 0.3s from either?

I'd refer again to this thread that goes more in depth about it. Either way I do agree with you that all of this is a problem, and the position refresh rate doubly so.

That post goes in depth about Latency and Animation Lock and how they compound each other to make the game feel clunky. However, I don’t see anything in it that directly addresses tick rate. If I missed something then please point me in the right direction. Those problems are alleviated by XIVAlexander and NoClippy that many players currently use, but they do not affect tick rate.

Tick rate was a separate issue earlier in the game’s life, as RedLolly mentioned:

To my knowledge, the last time we had a major netcode update was in response to Titan Hard, which had us memorizing every move, pattern, and where to stand so we could be well outside of landslide and bomb range a full second ahead because it was not tested with anything worse than Japan's great connections and nearby servers. (And it was meant to break you even then.)

I created a small diagram if that helps anyone grasp the concept:


The green line represents your character movement (what you see on your screen). The blue dots are the server recording your position at ~0.3s intervals. If a mechanic resolves in 0.7s, depending on where the tick falls, the server may only give you ~0.4s to react.


To reiterate, SE has not told us what the tick rate is currently so I can't know for sure if it's 0.3s. The point of this post is to say that whatever the tick rate is, it's insufficient for our current fast-paced encounters.

[Valence]

That post goes in depth about Latency and Animation Lock and how they compound each other to make the game feel clunky. However, I don’t see anything in it that directly addresses tick rate. If I missed something then please point me in the right direction. Those problems are alleviated by XIVAlexander and NoClippy that many players currently use, but they do not affect tick rate.

Tick rate was a separate issue earlier in the game’s life, as RedLolly mentioned:

Yeah I can see why we were speaking past each other because I don't have the same definition for what a server tick rate is. A server tick rate as far as I've known everybody talk about it, is the clock rate, aka the internal timing system that is also mentioned in the thread I linked notably on the third post on no clippy and xivalex, and seems to hint at an average 40ms give or take.

But if the thing you're talking about is only the player position refresh rate, yeah, as I agreed, it's terribad, no qualms about that, and it needs to be improved, especially for pvp if anything. But this still doesn't tell me where you got that it's 0.3s checks? I mean, it wouldn't surprise me that the server is that bad at checking positions mind you, because it shows.

Ultra minor nitpick, note that the eorzean clock which directly informs ingame time and HoT/HP/MP refresh ticks, is not every 3s but 2s and 11/12 (which is why full eorzean days take 70 irl minutes and not 72). Also note that DoTs aren't attached to the eorzean clock even though they have the same ticking interval, but are attacked to actors (aka, if you cast one dot, it will tick on the ability application after its delays, and if you apply more dots on top of the first one, they'll all align to the tick rate of the first because they're all yours).

[SkankyRoe]

Fully agree with OP. It's especially an issue when it comes to passable mechanics like P4s rots/tethers that can fail to pass to the person running through, and combine mechanics like those in High Concept/Pangenesis. It also makes for finicky as hell baited turrets like in P10s and M4s.

[Umbrasin]

But if the thing you're talking about is only the player position refresh rate, yeah, as I agreed, it's terribad, no qualms about that, and it needs to be improved, especially for pvp if anything. But this still doesn't tell me where you got that it's 0.3s checks? I mean, it wouldn't surprise me that the server is that bad at checking positions mind you, because it shows.

Ultra minor nitpick, note that the eorzean clock which directly informs ingame time and HoT/HP/MP refresh ticks, is not every 3s but 2s and 11/12 (which is why full eorzean days take 70 irl minutes and not 72). Also note that DoTs aren't attached to the eorzean clock even though they have the same ticking interval, but are attacked to actors (aka, if you cast one dot, it will tick on the ability application after its delays, and if you apply more dots on top of the first one, they'll all align to the tick rate of the first because they're all yours).

I understand now. You’re using “server tick rate” to mean the internal processing clock (~40ms), but I was referring to the positional/state update interval that tools like ACT/XIVAlexander show to average ~0.3s. Both exist, but they govern different layers.

Server clock (~40ms): Governs action triggers and internal scheduling. Much faster interval compared to positional tick, ~7.5x faster.

Positional tick (~0.3s): Governs when your position is sampled for mechanics and when HoTs/DoTs resolve. Much slower interval compared to server clock, ~7.5x slower.

For the HoT/DoT timing you’re correct that they are actor anchored and HoTs stack, but the combat interval is still ~3s real-time, not 2s11/12ths. The Eorzean clock is a separate system used only for timekeeping.

Fully agree with OP. It's especially an issue when it comes to passable mechanics like P4s rots/tethers that can fail to pass to the person running through, and combine mechanics like those in High Concept/Pangenesis. It also makes for finicky as hell baited turrets like in P10s and M4s.

Yes, I remember those janky turrets well. While I didn’t emphasize latency in my first post, the effective tick interval is always longer in practice since nobody has 0ms ping to the servers.

Effective tick length looks like this once you factor in latency (~0.3s base tick rate plus half your ping, since it's the one-way time for the packet to reach the server):

100 ms ping -> ~0.3s + 0.05s = ~0.35 seconds
150 ms ping -> ~0.3s + 0.075s = ~0.375 seconds
200 ms ping -> ~0.3s + 0.10s = ~0.40 seconds

This means that at 200 ms latency the server can be judging your position on data that’s nearly half a second old. For anybody raiding in Savage and beyond, a half a second lapse is an enormous amount of potential error.

[RedLolly]

I'm learning a lot in here, wow.

For some reason, I recall multiple instances of 230 ms ping being labeled a comfortable limit for high ping to still play FFXIV reliably. Years ago. That's half a second delay and still being able complete any encounter.

I've always played with high ping, every test getting around 190 to 210. I have one of my area's best services from my ISP. This fully explains *why* DT content suddenly feels so brutal while others just do not see or feel it as a problem beyond lack of skill. That comfortable ceiling got drastically lowered with zero change on how our games communicate with the server. Thousands of us are just screwed over.



That's bad.

[Umbrasin]

I'm learning a lot in here, wow.

For some reason, I recall multiple instances of 230 ms ping being labeled a comfortable limit for high ping to still play FFXIV reliably. Years ago. That's half a second delay and still being able complete any encounter.

I've always played with high ping, every test getting around 190 to 210. I have one of my area's best services from my ISP. This fully explains *why* DT content suddenly feels so brutal while others just do not see or feel it as a problem beyond lack of skill. That comfortable ceiling got drastically lowered with zero change on how our games communicate with the server. Thousands of us are just screwed over.



That's bad.

There's another factor at play that has helped bridge the gap (especially for those with high latency) which has helped fights feel more responsive but has a number of tradeoffs. SE uses server-side movement prediction to try and smooth the gaps between the positional tick updates. To help break it down:

• When you hit a movement key your client sends a packet saying “I’m moving forward/back/left/right.

• The server receives that input and assumes continuous movement in that direction until it gets another packet telling it you stopped or changed direction.

• This means that for mechanics like Titan’s Landslides, as long as you begin sidestepping early enough, the server will already be projecting your position outside of the danger zone even if the exact position packet hasn’t been received yet.

• This is also why you can move near an AoE and not go in it, yet be hit by it. It's the server prediction failing because it erroneously predicted you moved too far. The server didn't receive a new packet in time stating you stopped right at the edge.

That’s why you feel responsive movement in typical fights. The prediction bridges over the 0.3s tick + latency gap. Here's the problem, however, what if you need precise movements and positions, such as those required in more difficult fights?

• Savage fights often demand tight pre-positioning or last-second dodges (think P10S towers or P12S Phase 2 spreads).

• If you adjust direction suddenly (e.g., dodging out of a cleave at the very last tick), the server is still assuming your previous trajectory until your next position packet gets received.

• That means you can be visually outside on your screen, but the server thinks you were still inside when the mechanic snapshot occurred, so you get hit.

• This is why “move early, stop early” advice exists in high-end content. You’re basically trying to work with the prediction window so it doesn't kill you.

[Umbrasin]

What does all of that stuff just above mean?

At 100ms+ ping, that correction packet confirming your new direction takes longer to reach the server. Combine that with the 0.3s sampling window, and the server may be working with data that’s 0.35–0.40s old at the moment of mechanic resolution. Prediction can’t save you if your last-known “move vector” is wrong, so the faster and more precise the mechanic, the more punishing this gap becomes.

Movement prediction is what made older encounters feel playable despite the 0.3s tick + latency delay, since AoEs and slower mechanics gave the server’s assumptions room to be “good enough.” But with modern Savage and Ultimate fights now demanding sub-second prepositioning and sharp directional changes that same system falls apart. The result is that what once masked the lag now actively exposes it and and the cracks in the game's netcode.

This is why I ultimately decided on emphasizing the positional tick rate here. Increasing it would drastically improve positional accuracy on the server side, cut down on prediction failures, and make the modern fight design actually fun rather than feeling like we're fighting against the infrastructure.

[Ajisaii]

Everyone in this thread is wrong.