4 ms·
Yep. What you describe would be the expected behavior over a high-latency, but otherwise unloaded, connection. However, I'm wondering now: In the case of an ssh
by anyfoo 7y ago
Yep. What you describe would be the expected behavior over a high-latency, but otherwise unloaded, connection. However, I'm wondering now: In the case of an ssh session over someone's fully-loaded typical home Internet connection, might it be a mixture of both? Especially with buffer bloat and lacking any traffic shaping, can I expect that each individual packet (which can be reasonably mapped to a key press in interactive sessions) is queued right after the previous one? Assuming many many packets waiting for egress without any prioritization, when each keypress packet actually makes it out vs. any other will essentially be random, no?
- jrockway 7y agoNagle's Algorithm is also involved. It's why newer ssh-alikes use UDP (mosh, etc.)
- mikeash 7y agoLatency on a loaded connection can be really bad but it won’t be related to how fast you type unless the connection is really slow (like, early dial up modem slow). When you press a key, it will take a while to see the result. Depending on how things are set up, your computer will either send all subsequent keypresses immediately while you’re waiting, or it will buffer then and then send them all together once you get the reply. Either way, you won’t get this long term buildup.