The effects of modest TCP latency (I think) on my experience with some X programs
As I mentioned recently, I recently had an extended outage on my home Internet. When my Internet came back, it was a little bit different. My old home Internet was DSL with 14 Mbits down, 7 Mbits up, and about 7 milliseconds pings to work. The new state of my home Internet is still DSL from the same provider, but now it's 50 Mbits down, 4 Mbits up, and about 18 milliseconds pings to work at the moment. When my Internet first came back, I didn't expect to feel or see any real difference in the experience. It turns out that I was naive.
(Almost all of the ping latency is in the first hop, over my DSL link. Because I have a home Prometheus setup, I actually have historical data on ping round trip times, so I can verify the pre-outage details.)
As far as I can tell, my experience of plain text mode SSH sessions is unchanged, with nothing feeling any different. Unfortunately the same is not true of my use of remote X (as forwarded over SSH). Since early 2020, I've become accustomed to doing a number of lightly graphical X things over remote X; after my link came back, all of these started feeling various laggy and slow (especially my remote exmh, which I normally handle much of my email in). They weren't unusable, but they were sluggish enough to make me unhappy. I would type a key to take some action, and then I'd have a perceptible lag before the program's visible state updated, in a way I hadn't really had to before.
Interestingly, not all X programs are particularly affected by this. In particular (and conveniently for me), GNU Emacs doesn't seem to be; a a remote X session of GNU Emacs is quite snappy and about as responsive as a text mode version for most things (although not all of them). This has led to me suddenly being interested in reading my (N)MH email through GNU Emacs' MH-E mode (and then some other latency issues led me to build a little system for remotely opening URLs without the latency of remotely manipulating X properties). Since X text these days is all graphics (the remote client draws glyphs locally and then sends the drawn glyphs as graphical blobs), I'm not sure why this is, but part of it may be that exmh is written in TCL/TK, which haven't seen much work for a long time, while GNU Emacs these days is based on modern graphical libraries that may have seen more optimization.
Now that I've written it out, it seems obvious at some level that more than doubling my ping round trip times would have a visible effect. But on the other hand, it's not particularly visible in my text typing over SSH, and the vastly increased incoming bandwidth should help with X programs pushing big glyphs or graphics blobs to me.
(I think this impact on some X programs is more likely to be from the increased latency than from my decreased upstream bandwidth, but I admit I can't be sure.)
PS: In a way this was (and is) also an interesting experience in seeing how even a bit of response lag can cause people to be unhappy. Exmh was still pretty prompt in updating to show new messages and things like that, but just a little bit of visible lag between typing an 'n' and seeing the next message displayed was enough to get to me.
Comments on this page:Written on 09 September 2023.