Networked input lag

[silikone]

So the focus here is mostly on the issues surrounding displays and graphics hardware, but I miss seeing some more thorough documentation and explanation of how networked gaming affects the overall pipeline.
Now, the tried methods of measuring input lag are probably not going to be affected by networking, as game clients more or less simulate actions ahead of the server. The caveat of using client-side prediction is that it is bound to falter, which for a player can feel jarring as the game suddenly exhibits signs of lag that were otherwise not evident. How much a game can or should predict from the client is really a philosophical question without any correct solutions.
The aspect I find more promise in addressing is the packet/tick rate that is often notoriously low. Thanks to interpolation, multiplayer games can have the appearance of being smooth with as little as 10Hz. Analogous to video frame rate, the higher the packet rate, the lower the potential lag becomes. Ideally, a game server would send packets at the same rate as the client update rate just at the right time for them to arrive immediately before the beginning of a client game cycle.
I did some testing of my own in Quake on a LAN, as it allows for a lot of fine-tuning to test network performance. Setting everything to update at 60Hz, the game becomes pleasantly responsive on a client in spite of there being no client-side prediction. Disabling interpolation further increased the responsiveness, but it also exposed drifting that manifested as a jump or stutter at a regular interval. In this case, had there been a way to synchronize the frame rate with the server's tick rate, the experience would be flawless.
Of course, this becomes much more of a challenge across the internet, as ping times can become very volatile and almost impossible to synchronize.

[jorimt]

Not my realm, but Battle(non)sense posted an article on Blur Busters about this subject:
https://www.blurbusters.com/network-lag/

His YouTube channel covers this subject in-depth as well:
https://www.youtube.com/c/battlenonsense

[Chief Blur Buster]

Yep, Battle(non)sense is a great go-to for the network lag stuff!
On the other thing you mentioned -- tick rate synchronized to refresh rate.

<THOUGHT EXERCISE>

Synchronizing tick rates to refresh rates is also a challenge even if everyone is using exactly the same 144Hz or such.

There's a bit of clock drift between two separate PCs, that one computer is running at 144.003Hz and the other computer is running at 143.998Hz -- even though they're using exactly the same hardware, software, drivers, and running at the same temperature, etc.

Just like when you purchase two wristwatches, they never stay in sync forever -- they'll drift seconds apart over the period of a several days without synchronization. So you can't sync two ends, if they're fixed-Hz displays.

Now... VRR displays can provide a solution though, since refresh cycles are commanded via software whenever framerates are within the VRR range. So by this vein, it's possible to synchronize VRR displays to the software tick rate exactly on both ends. It'd even work if one end is G-SYNC and the other end is FreeSync! I wonder if any game developers have tried.

Hmmmm. We need VRR 240Hz displays overclockable to a little beyond >256Hz, so we can test 256Hz with CS:GO, synchronized to a multiple of the tick rate!

</THOUGHT EXERCISE>