120ms latency in network communication of game state is different from 120ms in input latency. We have client-side prediction in engines to ensure that the game world responds to input and view changes in soft real-time even though the server trip is still unfinished.
If your mouse cursor or terminal was continually an eighth of a second behind your input, you'd get pissed fast.
There is a post sometime in the last year here about a Microsoft Research tech demo which abused bandwidth to send all possible futures as well as the current screen, enabling client-side prediction to again eat one way of the trip.
This is the relevant technical details from the pcmag article:
Microsoft's DeLorean system takes a look at what a player is doing at any given point and extrapolates all the possible movements. It streams a rendering of these from a server to a player's console. Thus, when a player decides what he or she plans to do, that scene—for a lack of a better way to phrase it—is already ready to go.
I don't think competitive is the right word (I'm leaning towards "engaging"). Even if I'm casually gaming, it can be a turn-off to notice timing issues. More-so if I have to adjust my behavior to accommodate.
Well when I was younger I was very particular about these things (CRT vs early TFT etc) so I would not say that is not engaging at all. Just that you will probably be frustrated very soon when trying to outperform players with direct access in something like FPS
I tried to play GTAV when the first article came out, and while it wasn't unplayable, the latency was frustrating at best. Driving was futile, and I have a muc, much lower latency to aws than 120ms:
> ping -c 4 sdb.amazonaws.com
PING sdb.amazonaws.com (176.32.102.211) 56(84) bytes of data.
64 bytes from 176.32.102.211: icmp_seq=1 ttl=239 time=7.35 ms
64 bytes from 176.32.102.211: icmp_seq=2 ttl=239 time=7.51 ms
64 bytes from 176.32.102.211: icmp_seq=3 ttl=239 time=7.11 ms
64 bytes from 176.32.102.211: icmp_seq=4 ttl=239 time=7.15 ms
--- sdb.amazonaws.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 7.119/7.285/7.512/0.180 ms
7.5 ms of latency will not degrade your gaming experience, I'm pretty sure. If you're gaming at 60 fps, and move your mouse right after a new frame is displayed, the mouse movement won't be visible until the next frame, 16.66 ms later. And 60 fps feels smooth to me.
On my home internet connection, pinging, for example, google.dk gets me a response time of a few milliseconds, and a HTTP GET request for the root URL has the same latency. But if I do a HTTP GET request as part of the search, the latency is much higher.
I think the google.dk/com main page (and probably other heavily visited sites) are cached by ISPs, so that you don't necessarily reach Google when you ping or HTTP GET the root domain, but rather some network cache device between you and your ISP.
So be careful trusting that ping latency necessarily equals HTTP GET latency, or latency for some other request, to a server.
That is weird. It should be worth investigating if you have any other bottle necks that are increasing the latency. Monitors for example, usually have a response time, from input to when you see the image, of around 10-20 ms.
Input > PC > amazon > PC > monitor
Maybe there's something in your PC that is adding to the lag, like a slow software render.
It could also be that the machine answering to the ping is closer due to anycast routing.
Can anyone come up with a practical way to measure the actual lag from input to screen render!? For example using a high speed camera.
The decoding was in hardware, and I have dual amd 7850s, so I don't think that was the issue (and I wasn't trying to run at the full 4k either)
There was a very noticeable input -> display lag, according to telemetry on steam it was ~40ms total, which is fine for a lot of games, but really noticeable and annoying for something like gta. I mean I've played civ5 over vnc before, and 40ms would be a godsend compared to that, but it was still more than playable.
Latency will only be an issue if it's non-constant - most gamers can adjust for lag if it's expected.
I think the underlying idea here is consistency. If I point and click on something that was merely a "mirage" due to network effects, then this is somewhat of a bad experience.
> If you have a general latency of 120ms, then the maximum number of frames per second which react to distinct instances of input is 8.
If you have a round trip latency of 120ms, then the maximum number of action-result-reaction cycles per second is 8, but its possible to have distinct instances of input to information received each frame whether or not that frame accounts for input in the previous frame. You can have distinct instance of input -- and frames that react to them -- as fast as you can show frames and humans can process them. The frames showing the reaction will be delayed by the latency + human response time from the information they react to, but the frequency of those frames is pretty much unconstrained by latency.
Which is why, again, slow frame-rate and high latency are orthogonal (both create the perception of "slowness", but they are different and independent effects.)
The only real relation is that a low frame-rate can mask high-latency, as if the latency (including human response time) is less than time between frames, the latency becomes imperceptible. So, yeah, 8 FPS becomes the frame rate necessary to completely mask 120ms latency.
> If you have a round trip latency of 120ms, then the maximum number of action-result-reaction cycles per second is 8, but its possible to have distinct instances of input to information received each frame whether or not that frame accounts for input in the previous frame. You can have distinct instance of input -- and frames that react to them -- as fast as you can show frames and humans can process them. The frames showing the reaction will be delayed by the latency + human response time from the information they react to, but the frequency of those frames is pretty much unconstrained by latency.
Got it. That makes sense. I was putting the user more in the mindset of a webapp user, where almost all interaction is "action-result-reaction," but when I think about gaming, I am giving a pretty much constant stream of input, coming from a join flow of muscle-memory, my own desires for the outcome, and the input of the visual and audio.
So, sure, I will take many more than 8 actions, and all of them will just be delayed.
120ms doesnt limit the game to 8 FPS though - it means that the image is at ~60 FPS and 8 Frames into the past.
120ms is perfectly fine for RTS and most RPGs or even MMOs... Though MMOs would probably get another ~30ms increase in latency because of the connection from aws to the game servers.
If it wasn't a direct feedback game with mouse to look. I'm sure it wouldn't matter aS much. Such as point and click. Or click to move rpg. Rts. Etc. I'm sure if it was mouse to look or aim. Or even a strong key press to move it'd be noticeable. But still could be great for plenty of games. Though not all
