Why I don't use caves

[Zeruul]

So should DST caves work like DS caves, which doesn't require an alternate server running simultaneously?

When a player is about to enter a cave/ruin, the server will activate a prompt/vote for other players. If all/most players accept, it will be similar to DS: cave will be generated and everyone will be put into a loading screen. However, players cannot be both on the over-world and cave/ruins simultaneously. Take Left4Dead series for example. 

It would allow us to have 3 caves 3 ruins just like DS, or even make the teleportato possible

[. . .]

Just now, Zeruul said:

However, players cannot be both on the over-world and cave/ruins simultaneously.

Only as an config option, because I myself like making my base in caves while my brother likes living on land & having something like this would ruin everything!!!!

[HomShaBom]

I tested it out, spawned in 20 "carrot_planted" and picked them up with caves turned on and with caves turned off. It's was about a 20% difference in the time it took to pick up all the carrots. 20% is significant. And this was just picking up carrots. It get worse when you're in combat. If you think the lag is not a big deal, that just means you're not aware of what you can actually do in Don't Starve without any latency.

[StarvedKasad]

6 minutes ago, Zeruul said:

So should DST caves work like DS caves, which doesn't require an alternate server running simultaneously?

When a player is about to enter a cave/ruin, the server will activate a prompt/vote for other players. If all/most players accept, it will be similar to DS: cave will be generated and everyone will be put into a loading screen. However, players cannot be both on the over-world and cave/ruins simultaneously. Take Left4Dead series for example. 

It would allow us to have 3 caves 3 ruins just like DS, or even make the teleportato possible

The devs actually had a merged world back when the game was still in alpha or beta I don't know,however they changed it to make the game less heavy.I tried a similar approach.I added a mod that generates an even bigger world that adds cave areas on the outskrirts of the overworld.The game performed as without caves,the extra latency was non existant. However this also requires a better rig to run it,which of course I had. The extra latency is unacceptable for a decent don't starve experience.

[CarlZalph]

6 hours ago, Mday said:

Do you mean hosting different shards on different PC? or Do you mean hosting different shards on the same PC?

I am not expert on this, but apparently the game has very limited muiltcore support. A shard can have 1 CPU core stresss to 100%, causing lag to everyone on the server, while the remaining CPU cores remain mostly idle. The cave is make into a whole separate shard (and hence using a different CPU core) so that it can help relief some of the load from the surface world.

This is correct, the LUA state was not designed to be multithreaded, and as such it doesn't have some of the required components needed to avoid concurrent issues.

3 hours ago, zazabar said:

So a mod that made the lantern craftable away from the Alchemy Engine would be good then?  Maybe one where you can just craft the blueprint for free off of it and use it instead of having to prototype.

I suppose that could be a solution.

I'd probably make it so that the recipe is just known like a torch is at the start to help promote going to the caverns at an earlier game state.

Since Klei wants more people in caverns this could help with that.

47 minutes ago, StarvedKasad said:

YES THE LAG finally someone besides me mentioned it.It's not about the specs,the game has a very strange mechanic that adds to every move you do an average of 0.2 ms delay. And this is even more apparent when you use the queue mod. You have to pick 100 grass/twigs and instead of finishing it in say a minute,it takes 1,50 or maybe even 2 minutes.Oh you wanted to micro the boss and you are even the host?No can do!Better stick to non caves version buddy!

Seriously ,with all due respect to your amazing game,this is bad programming. I'm suspecting they are adding an inherited delay because it can't be explained otherwise. And to make matters worse the delay is the same on small and huge maps so it's deffinitely something with how the game handles the caves and adds a default delay,which is horrible.

The game's networking model is done via the client->server->client protocol, which is to say the client waits for the server to respond back with actions before taking more actions.

However, one current way around this is to issue multiple pickup commands in a short time spam under the assumption that the server's tickrate is constant and no spikes of latency arrive.

Basically tell your guy to pick up an item and during the animation give it another pickup command and the person will pickup as fast as possible.

Whether or not this model is good is debatable, though it's the safest approach to avoiding cheaters by making the client only have inputs to send while the server does all the heavy lifting of simulation.

So if there's an exploit or bug then only the server-side code is to blame.

[nome]

16 hours ago, HomShaBom said:

The problem with caves, for me, is really a problem with the whole game. The lag is just awful. I don't understand why DST has the worst lag problem of any game I've played. When I play Dota 2, everything is snappy and responsive. When i click somewhere my character moves immediately. In DST when I'm hosting a server I can hit a koalefant or a beefalo 7 times between its attacks and dodge its attacks and never get hit. When I fight a Hound, Clockwork Knight, or Tallbird I can easily dodge their attacks and hit them 2-3 times betwen their attacks.

Games that were designed to be multiplayer from day one are better at hiding lag than DST. The lag is still there, but you don't see it because the game has tricks to hide it from you.

 

[EuedeAdodooedoe]

15 hours ago, Sinister_Fang said:

1) You see, it's rather unfair to compare a game like DST, Minecraft, Terraria, ect. to something like Dota 2. These types of games are hosted in various locations with systems of wildly different hardware. So lag tends to be more of an issue in these types of games. Something like Dota 2 likely have their own servers all running on the same or at least similar hardware. On top of that they likely have a lot of experienced people who deal with the networking code and server maintenance.

2) And then there's also the problem of Don't Starve not being built for multiplayer. A lot of work went into making Don't Starve Together but there's only so much that can be done to compensate for latency in a game that wasn't originally built to handle it.

TL;DR: You're gonna have to deal with the subtle lag. It's really not that hard to get used to, especially if your the host.

1) Then why does Klei have a master server? For the sake of skin drops? But you can't play the game without connecting to the main server unless you're playing offline. So, they want all online server to be connected to the main one? Why? Skins aren't that important that Klei needs to have all servers connected to their master server for you to play online do they?

2) How is "not being built for multiplayer" have anything to do with lag? Changing the game to fit multiplayer is precisely something that should eradicate lag. I'm a bit confused as to why the game gives so much lag in the first place when on-screen you don't actually have much going on usually. When bases are loading, they may give you lag more than anything aside from huge groups of beefalo or spiders or something, but why? None is interacting with these things at all, they're just drawn objects that don't even move or have active animations, so what the hell? And I'm talking about chests, crock pots, ice boxes, drying racks (unless meat is drying), farms, stations when you're not near them and probably other things.

All in all, this just doesn't seem to make enough sense to explain the lag, at least to me, considering people have good wifi connections and have the hardware requirements met.

[KadeNovakid]

The reason they have a main server is because without it people could edit the files on their computer to get any skins they want, and since the skins can be sold for anywhere from $0.03 to $32.97, Steam doesn't really want this to happen.

[verm1ll1on]

12 hours ago, GiddyGuy said:

Also note for the devs, if you were truly saying you didn't see too many people having caves enabled then it's probably because most can't handle them and just play without them, at least that's my theory since I myself can not play with caves enabled.

What he said. I just love the exclusive content made DST, the skins are a up, the higher difficulty to kill mobs and all that, but I like going for long runs as well. I too can't host my own server with caves enabled (I can't even kite the Deerclops with caves enables on day one, so imagine how laggy the whole thing will be by day 200), so I'm playing vanilla Don't Starve again.

 

If none of DST features are ever going to make it into the single player version, could you guys at least fix the fire animation? It stays outside the firepit and it bothers more than it should ):

Spoiler

 

[nome]

8 minutes ago, EuedeAdodooedoe said:

1) Then why does Klei have a master server? For the sake of skin drops? But you can't play the game without connecting to the main server unless you're playing offline. So, they want all online server to be connected to the main one? Why? Skins aren't that important that Klei needs to have all servers connected to their master server for you to play online do they?

Klei login servers verify your identity. If we're both playing LAN mode I can claim to be you and the game will just believe me, kick you off and let me play your guy. Good griefing potential there if that was the mode we used on public servers! Item servers do skins, they're a separate service though they rely on the login server and thus being in online mode.

10 minutes ago, EuedeAdodooedoe said:

2) How is "not being built for multiplayer" have anything to do with lag? Changing the game to fit multiplayer is precisely something that should eradicate lag. I'm a bit confused as to why the game gives so much lag in the first place when on-screen you don't actually have much going on usually. When bases are loading, they may give you lag more than anything aside from huge groups of beefalo or spiders or something, but why? None is interacting with these things at all, they're just drawn objects that don't even move or have active animations, so what the hell? And I'm talking about chests, crock pots, ice boxes, drying racks (unless meat is drying), farms, stations when you're not near them and probably other things.

You can never eradicate lag, you can only hide it. Any game where you're not in the same process as the server will have lag between when you take an action and when that action really happens. But games designed for multiplayer are able to hide this better - for example in an FPS the game's netcode might get the fact that you shot at another player long after he's moved outside your area of effect, but still allow the hit to go through based on where he WAS when you pressed the fire button. This is harder to notice, but it's still there and can lead to some pretty frustrating moments when you get shot by some laggy player while you were clearly behind cover.

[DarkXero]

9 minutes ago, nome said:

You can never eradicate lag, you can only hide it. Any game where you're not in the same process as the server will have lag between when you take an action and when that action really happens.

But how come there is this extremely minuscule lag when the server is in the same machine as the client?

The lag comes from the client input going to the router and then back to the machine?

The lag comes from the way the server handles the client input?

What is the difference between an offline server without caves and one with caves?

[StarvedKasad]

15 minutes ago, nome said:

Klei login servers verify your identity. If we're both playing LAN mode I can claim to be you and the game will just believe me, kick you off and let me play your guy. Good griefing potential there if that was the mode we used on public servers! Item servers do skins, they're a separate service though they rely on the login server and thus being in online mode.

You can never eradicate lag, you can only hide it. Any game where you're not in the same process as the server will have lag between when you take an action and when that action really happens. But games designed for multiplayer are able to hide this better - for example in an FPS the game's netcode might get the fact that you shot at another player long after he's moved outside your area of effect, but still allow the hit to go through based on where he WAS when you pressed the fire button. This is harder to notice, but it's still there and can lead to some pretty frustrating moments when you get shot by some laggy player while you were clearly behind cover.

Very interesting.How do you explain the extra latency when adding caves though?They are not that big compared to a huge overworld,why does the game seems to add a default latency when playing with caves?

[CarlZalph]

57 minutes ago, CarlZalph said:

The game's networking model is done via the client->server->client protocol, which is to say the client waits for the server to respond back with actions before taking more actions.

5 minutes ago, DarkXero said:

But how come there is this extremely minuscule lag when the server is in the same machine as the client?

The lag comes from the client input going to the router and then back to the machine?

The lag comes from the way the server handles the client input?

What is the difference between an offline server without caves and one with caves?

The latency arrives from the client sending its data to the router and then to the server and then back to the router to the client, yes.

The way the CSC protocol works will force latency to happen due to the client waiting for the server to respond back before taking more actions.

An offline server without caverns the client and server are one and the same so no networking takes place, whereas once caverns are enabled then the client server is setup in shard format, forcing networking.

[DarkXero]

4 minutes ago, CarlZalph said:

The latency arrives from the client sending its data to the router and then to the server and then back to the router to the client, yes.

The way the CSC protocol works will force latency to happen due to the client waiting for the server to respond back before taking more actions.

So we can't make it so the computer talks to itself?

If I get the internet cable and plug it to my PC, my computer will talk to itself or it will talk with the ISP's whatever they have?

If I'm not connected to any network, what happens?

[CarlZalph]

Just now, DarkXero said:

So we can't make it so the computer talks to itself?

If I get the internet cable and plug it to my PC, my computer will talk to itself or it will talk with the ISP's whatever they have?

Network drivers can notice when a device is trying to talk to itself and not use the router to redirect the traffic to the same device, but it won't ever reach the ISP due to the router definitely knowing that the device is talking to itself.

[DarkXero]

1 minute ago, CarlZalph said:

Network drivers can notice when a device is trying to talk to itself and not use the router to redirect the traffic to the same device, but it won't ever reach the ISP due to the router definitely knowing that the device is talking to itself.

So why isn't this happening here? Why the communication has to be client-router-server-router-client?

Or that is actually all happening inside the same computer and it takes so long you actually notice, despite all being the same hardware?

[CarlZalph]

1 minute ago, DarkXero said:

So why isn't this happening here? Why the communication has to be client-router-server-router-client?

Or that is actually all happening inside the same computer and it takes so long you actually notice, despite all being the same hardware?

It's happening when caverns are enabled because the client and server are separated.

This latency is noticeable because it is double the latency between client and server due to the client waiting for the response.

A way Klei could have done this is to just assume the delay from the client to the server is all that's needed for actions, but it doesn't guarantee that the action fully finished on the server before the client starts another actions.

For instance, if a client starts picking a grass shoot under this new system and then moves right as it finishes, but the server had a slight choke and missed a tick, then the client won't be granted the grass because on the server the client moved a frame too early; this can cause frustration to the client.

This could be negated by having the client tell the server that the client fully finished the picking, but that puts trust on the client and opens up the possibility for exploiting (instant picking, N frame early picking).

This system would cut the latency in half but at the prices aforementioned.

 

An example of this in place was Minecraft, and breaking blocks.

There were exploited client builds that allowed its users to instantly break blocks, and then that was patched.

Then it allowed clients to break blocks ~20% quicker than normal, and then that was eventually patched.

Block breaking is now in a hogpog state wherein the client predicts its breakage, but if the server disagrees for any reason then the client can be breaking blocks in the future that it can't see and thus can't break, and so the client gets in a limbo until it gets an update on the chunk to see all of its progress reverted.

[StarvedKasad]

35 minutes ago, CarlZalph said:

It's happening when caverns are enabled because the client and server are separated.

This latency is noticeable because it is double the latency between client and server due to the client waiting for the response.

A way Klei could have done this is to just assume the delay from the client to the server is all that's needed for actions, but it doesn't guarantee that the action fully finished on the server before the client starts another actions.

For instance, if a client starts picking a grass shoot under this new system and then moves right as it finishes, but the server had a slight choke and missed a tick, then the client won't be granted the grass because on the server the client moved a frame too early; this can cause frustration to the client.

This could be negated by having the client tell the server that the client fully finished the picking, but that puts trust on the client and opens up the possibility for exploiting (instant picking, N frame early picking).

This system would cut the latency in half but at the prices aforementioned.

 

An example of this in place was Minecraft, and breaking blocks.

There were exploited client builds that allowed its users to instantly break blocks, and then that was patched.

Then it allowed clients to break blocks ~20% quicker than normal, and then that was eventually patched.

Block breaking is now in a hogpog state wherein the client predicts its breakage, but if the server disagrees for any reason then the client can be breaking blocks in the future that it can't see and thus can't break, and so the client gets in a limbo until it gets an update on the chunk to see all of its progress reverted.

Nice explanation. I guess Klei have to put together a better system at predicting the movements (for halved latency) as well as add more protections against client based mods.Because you can already do those abuses with server mods.

[EuedeAdodooedoe]

2 hours ago, nome said:

1) Klei login servers verify your identity. If we're both playing LAN mode I can claim to be you and the game will just believe me, kick you off and let me play your guy. Good griefing potential there if that was the mode we used on public servers! Item servers do skins, they're a separate service though they rely on the login server and thus being in online mode.

2) You can never eradicate lag, you can only hide it. Any game where you're not in the same process as the server will have lag between when you take an action and when that action really happens. But games designed for multiplayer are able to hide this better - for example in an FPS the game's netcode might get the fact that you shot at another player long after he's moved outside your area of effect, but still allow the hit to go through based on where he WAS when you pressed the fire button. This is harder to notice, but it's still there and can lead to some pretty frustrating moments when you get shot by some laggy player while you were clearly behind cover.

1) Aside from you being a troll, is there any significant benefit to you "knowing our true identity"? You're not banning anyone from the game itself, so, why?

2) Yeah, but why is the latency so severe even for those who have good connection and good computers when prediction is enabled (which renders the game unplayable when you easily could, so I don't know why you have prediction set as enabled by default)? You just have a bad master server or something?

[nome]

1 hour ago, EuedeAdodooedoe said:

1) Aside from you being a troll, is there any significant benefit to you "knowing our true identity"? You're not banning anyone from the game itself, so, why?

We don't really care about your true identity, we just care that you're the same person you were last time (KU_blahblah, literally a random string). The reason is that this is what lets you make someone an admin on your server, or ban them, or anything else really. If the game always operated in offline mode, trolls who were banned could just change their account number every time you banned them and rejoin. Or rejoin using the account of the server admin who banned them! All seem like pretty compelling reasons to me. Basically, without identity a lot of things don't work.

 

1 hour ago, EuedeAdodooedoe said:

2) Yeah, but why is the latency so severe even for those who have good connection and good computers when prediction is enabled (which renders the game unplayable when you easily could, so I don't know why you have prediction set as enabled by default)? You just have a bad master server or something?

Klei services are not involved in any way, shape or form in your lag experience. When you pick up a carrot off the ground, that communication is between you and the game server (hosted by whomever), it doesn't talk to any Klei hosted service, whether you're in offline or online mode. The game talks to the login service whenever a player joins the world to verify that they are who they say they are (Hey, is this guy really KU_BlahBlah?) and after that you're done.

There's a bit of a contradiction in what you're saying - as I've already explained, physics prevents any game from "fixing" lag. All you can do is hide it. Movement prediction is our attempt at doing just that. You can argue it's not doing a very good job, but it's the best we've got so far - shoehorning netcode into a single player game isn't simple. The best techniques require the ability to rewind the sim and play different inputs, which we don't have.

[Pyr0mrcow]

...didn't realize that there was actually a problem with multi-cores. I guess that'd explain the slight response delay I get with hosting a cave server despite outdoing the game's listed specs by a fairly large amount, mine is 8GB, 2.8ghz, but it's split into 4ths.

Anyway, everything relevant is constantly being sent back and forth between the server and the player. The amount of information could perhaps be lowered, but that distance between everyone involved in that transfer will still exist. Individual game servers are hosted all over, so lag's even more impossible to control directly.
LoL had similar issues for a while. Difference being, everything of theirs goes to 1 server per region, while we're player-based, and games like that have options that we don't.

Spoiler

Easy way of explaining it, green line is ideal, red line is normal; information gets interrupted and delayed all over the place.

 

...maybe if more were added to prediction, it wouldn't be so bad. I feel like the main problem is hit registry, both giving and receiving...but how would that be handled? Can't base it solely around when an object is hit client-side, because that's way too easy to abuse...
Could maybe combine client-side hit with reasonable proximity? Still, people could make themselves unhittable that way. Can't just kick people out if they never get hit, because some of us are really, really good at kiting when playing with no delay.

Another slightly less dangerous prediction that could be added is one for picking resources from plants, or items from the ground. That takes significantly longer on some servers, resulting in gathering trips taking up to twice as long, and being a lot less efficient, unless you've figured out the exact timing that the server requires; but even then, it usually takes longer. Doesn't matter if the item sits idle for a moment server-side, if the item makes it into the player's inventory immediately client-side, and when they appear to be picking it up server-side, that's less time spent standing in place waiting for it to work, or trying to predict how long you need to stand over it before moving to have it magically appear in your inventory after you've walked away (which is what I do currently).
...potentially, that could run into a similar problem with Minecraft's block disappearances...but that already happens occasionally when moving items around in your inventory. The movement doesn't register, so the item jumps back to its previous position.
I'm not sure if it was fixed or not, but a while back, the items would even disappear occasionally; but clicking in the blank spot where they were before fixed it, so it wasn't big.

[Mday]

I wana talk about the movment prediction. There seems to be some changes in how it works.

This is how movment prediction works to me at 250 ping BEFORE(about half a year ago):

I cannot kite a terrorbreak with 250 Ping. If I kite the terrorbreak according to the game animation, I will always get hit by the thing, and I can never get my attack registered. To actually kite the terrorbreak I have to tank the first hit, attack the terrorbreak, dodge, attack the terrorbreak and so on. When doing so the animation will looks like as if I have been hit by the terrorbreak all the way. This same trick can be used to kite the clockwork knight and pig, except if I time it right I dont have to tank the first hit. The animation will still looks like I wield a pair of Sharingan and has Izanagi activated.

And this is how movment prediction works now:

Now, I can kite a terrorbreak according to the animation, which is dodge, attack, dodge and so on. The main issue is with the werepig. The werepig has become very difficult to kite. Now I can attack the werepig 2 times, none of the hits get registered, and then I dodge the werepig's attack. I turn around to hit the pigs 2 times again, and this time I will have 1 of the hit registered. After I dodge again, and attempt another two attacks, these two hits will not get registered. So effectively for every 3 hits I can only have 1 hit registered.

[DarkXero]

6 hours ago, CarlZalph said:

It's happening when caverns are enabled because the client and server are separated.

This latency is noticeable because it is double the latency between client and server due to the client waiting for the response.

I am just in disbelief that having two programs talking between each other is noticeably slower than having one talking with itself.

while true do
	HandleInput()
	UpdatePhysics()
	Render()
end

while true do
	ProcessPackets()
	HandleInputs()
	UpdatePhysics()
	FeedClients()
end

I imagine the game loops (single player and multiplayer) would be like this or something alike.

If ping is practically 0 because everything is on the same PC, how come it takes so long it's noticeable?

Why the input going from keyboard to game doesn't cause delay compared to input from keyboard to socket to game?

Or it's the creating the data to tell the clients what changed in the world the part that it's expensive?

 

If I set the server tick_rate to 60, the delay gets reduced because pipelining? But in this case, if I don't have movement prediction, then Wilson vibrates when moving. And if I have movement prediction, sometimes I can get hit from weird angles (as in I was just barely getting away from that spider).

[Kzisor]

18 minutes ago, DarkXero said:

Why the input going from keyboard to game doesn't cause delay compared to input from keyboard to socket to game?

Or it's the creating the data to tell the clients what changed in the world the part that it's expensive?

Input from Keyboard to Game can happen during the same game loop.

Keyboard to Game to Socket (Send Information) to Socket (Retrieve Information) to Game must happen across multiple game loops.

A game loop will first determine if there is any input from the keyboard. If there is input it will process the input. If there isn't any input or the input has been processed then it will finish the game loop. Sending and retrieving information usually happens in a separate thread. However, the information received from the socket must then be queued into the game loop; which can only be processed on the next frame or game loop.

[CarlZalph]

2 hours ago, DarkXero said:

I am just in disbelief that having two programs talking between each other is noticeably slower than having one talking with itself.

while true do
	HandleInput()
	UpdatePhysics()
	Render()
end

while true do
	ProcessPackets()
	HandleInputs()
	UpdatePhysics()
	FeedClients()
end

I imagine the game loops (single player and multiplayer) would be like this or something alike.

If ping is practically 0 because everything is on the same PC, how come it takes so long it's noticeable?

Why the input going from keyboard to game doesn't cause delay compared to input from keyboard to socket to game?

Or it's the creating the data to tell the clients what changed in the world the part that it's expensive?

 

If I set the server tick_rate to 60, the delay gets reduced because pipelining? But in this case, if I don't have movement prediction, then Wilson vibrates when moving. And if I have movement prediction, sometimes I can get hit from weird angles (as in I was just barely getting away from that spider).

Let's assume that the delay you're seeing is about 0.1 seconds in duration, which is 100ms of delay.

 

When the client is the server there is no networking and as such there is no delay from keypress to actions to visibility on the client, aside from any GPU rendering delays (~16.6-ms at 60Hz refresh rate-- Neglect this.).

In the client server case networking happens, and the client will wait until it gets a response back from the server before doing another action so the client->server delay is added to the server->client delay, or roughly double the ping value.

Tick rate on the server is default 15Hz, so its logic only happens every 66.6- ms

The game when it processes the inputs of clients will then shoot out a response either the same frame or the next frame, so either 0 or 66.6- ms of delay (Valve's Source engine always spits data back the following frame) is added to the total delay.

 

The game won't process inputs until the tick hits where all the logic happens, and the packets are interpreted and simulated from inputs.

If your packet arrives right on the falling edge of a tick, which is to say right after the server is done processing packets it has accumulated, then you must wait until the next frame to process, which would be 66.6- ms, before the server will tell you what happened.

(This is why Valve chose to send on the following frame, to enforce consistency between inputs and simulation time, rather than having inputs that go right before a tick having an inherent advantage over inputs that happen right at the end of a tick.)

 

Worst case:

Inputs are received by the server on the falling edge of a tick, and the server sends back data only on the following tick.

(client ping C->S) + 66.6- ms + 66.6- ms + (server ping S->C)

Since the client and server are the same device, but still going through a router, there is a delay and so C->S and S->C values are not zero but not too high depending on the router/networking driver.

Minimally you'd be waiting a bit over 133.3- ms, which is over the 0.1 seconds.

 

Best case:

Inputs are received by the server on the rising edge of a tick, and the server sends back data on the same tick.

(client ping C->S) + 0 ms + 0 ms + (server ping S->C)

Only the router latency would take into factor, which is not zero but still marginal enough to not take into consideration.

But, if the server sends data back on the following tick, which I think it does, then you'd be looking at the 66.6- ms delay.

 

At 60Hz tick rate the frames are 16.6- ms of delay and as such you should see more responsive actions with the worst case giving at least 33.3- ms of delay.