8 hours ago, Tipotas688 said:

I think what would make your answer more complete would be to increase the speed of interpolation by something small so that it eventually catches up to the extra latency that was setup

No, because that's not necessary, nor does it make sense. If the object is moving, then your local interpolated data will continually be following those positions, N milliseconds in arrears, where N is the length of the buffer you chose. If the object is not moving, then your local version will catch up to the final position within N milliseconds. There is no need to change the speed of anything.

The point of this sort of system is that a state update takes some length of time (say, 'M') to reach the client from the server, and then some length of time (say, 'N') before the client fully reflects that change, to help ensure the client has received another state update from the server before the current one is reached.

You can adjust N slightly on a per-message basis to account for fluctuations in M. In other words, if a message arrives sooner than expected, you might want to take longer to interpolate towards it, and vice versa. This keeps movement smooth.

It is reasonable to consider decreasing N during play so that it's not too long and imposing unnecessary client-side latency. This will be determined by M and your send rate.
It's also reasonable consider increasing N during play so that it's not too short and leaving entities stuttering around, paused in the time gaps between reaching their previous snapshot position and receiving the next snapshot from the server. This is determined by the variance of M (jitter) and your send rate.

Often N is left at a fixed value (perhaps set in the configuration), picked by developers as a tradeoff between the amount of network jitter they expect to contend with, and the degree of responsiveness the players need to have. And if you're happy occasionally extrapolating instead of just interpolating, i.e. you are happy to take less accuracy for less latency, then you can reduce N down even further.

The idea to "catch up earlier" doesn't make sense in isolation. Earlier than what? The idea is that you always allow yourself a certain amount of time to interpolate smoothly towards the next snapshot because you still want to be interpolating when the subsequent one comes in. You don't want to be decreasing that delay over time because of the stuttering problem above, unless you have sufficient information to be able to do so.

It's not entirely clear what you're asking. Let's strip it back to the basics: every networked game where there are entities with non-deterministic movement (e.g. a player-controlled object that changes direction when the player chooses) is going to have to send a stream of updates about its current state ("snapshots"). Those updates will come in less frequently than the visual frames are displayed, and therefore you have a choice of no interpolation at all, meaning the object moves immediately, but in a jerky and disjointed manner, or you apply interpolation between those snapshots, meaning it moves in what appears to be a smoother manner but which must be done over a period of time following the inbound message. That's pretty much a fact of life, whether you need 'accuracy' or not, whether it's a skill game or not.

What you then get to choose, are a bunch of tradeoffs about how you apply this stuff, and it's basically "low accuracy, low latency" at one end of the continuum and "high accuracy, high latency" at the other end of the continuum. There is no magic "high accuracy, low latency" approach because information necessarily takes time to travel. You can reduce the latency by using extrapolation instead of just interpolation, but the very nature of extrapolation means it will sometimes make incorrect predictions, and that you've traded away some accuracy. Sometimes that is the right choice for your game.

3 hours ago, Tipotas688 said:

Sure I'm with you, I think I'm reaching the same conclusion that extrapolation is required. The test game I'm making ( pong ) is sending 30 packets a second, basically every frame to make sure I get the best result possible. If I lose a packet I use the next one, if there's a delay I snap to it. 

What I notice is that a user that has 100ms delay plays with issues that are game breaking, a user that has 60ms plays much better. Being a pong game it needs accuracy to play ok and as you say there are trade-offs but I'm currently not seeing great results even though I have such low latencies. Makes me wonder whether a game like pong can be done with just snapshot interpolation or whether it also needs extrapolations as well

There are a lot of unknowns which can affect how your game works.

1. You've not posted any code that proves you're sending at 30Hz. It's very easy with modern libraries to call something 30 times a second but for it to only be actually sending something once a second or after 100ms or similar. That adds latency.
2. Similarly, even if data is being sent 30 times a second, we've not seen the code that guarantees it is being read at a similar rate. It is common for networking libraries to buffer up input and only poll it occasionally.
3. Even if somehow it was possible that your reads and writes are hitting the wire instantly, the server processing loop also tends to add latency. If the server runs at 30Hz then that's an additional 0 to 33ms per message to relay it to someone else.
4. 100ms and 60ms are not really "low latencies", generally speaking. It depends on whether you're talking about LAN or WAN, and whether this is the round trip time or the direct time, and whether this is measured at the application level or the network level. It's useful to take these different measurements to see where the time is being spent.
5. Pong is a game where the paddles might move the entire height of the screen in a second. If it takes 100ms to get the message to the other player then they're going to see the paddle perhaps a whole tenth of the screen distance away from where the the controlling player sees it. If you add even just 1 frame of interpolation onto that then you're looking at pushing that error up from 10% to 13 or 14%. However...
6. ...usually this doesn't matter. The goal is almost never to have two clients entirely synchronised (because it's impossible), but to make the game playable. The game, in this case, usually only has 1 paddle where the position really matters at any given time. You can use extrapolation on the server to see that a player would 'probably' hit the ball even if it doesn't exactly reach on the server, for example.