The effects of modest TCP latency (I think) on my experience with some X programs

September 9, 2023

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:

By Patrick at 2023-09-10 05:36:48:

Hi Chris,

I can highly recommend fiber based Internet access. My first hop latency dropped from around 20ms to around 2ms after the migration from VDSL to fiber Internet access. I think this is mainly due to the fact tat digital to optical and back is much faster than digital to analog transformation. Everything feels faster/snappier with fiber based access.

Best Regards, Patrick

By Opk at 2023-09-10 06:00:16:

The Internet providers always focus on the raw bandwidth figures in their marketing material. I've had to get "upgrades" reverted in the past due to increased latency making it actually worse. I'm stuck with home Internet using cable TV infrastructure as my only option which is typically worse than ADSL for latency. Despite downloads and netflix being fast, I find remote desktop software like VNC to be barely usable and I generally get complaints from others about my signal in video conferences. Adding a router with fq_codel enabled did improve things slightly. I'd recommend trying that, especially if you only see poor latency under load implying a possible bufferbloat problem.

From at 2023-09-11 01:15:22:

18 ms to work over DSL still sounds pretty good. I was pretty surprised when we had to upgrade from (8 Mbps down, 0.4 Mbps up) ADSL to a fixed LTE/4G connection and the latency actually went down a little.¹

From what I found out, I believe it was caused by the DSL "interleaving" feature, which is supposed to make it more noise-resistant but by its nature needs to buffer a lot of data (so that it would have something to interleave). It might be that your ISP can agree to turn it off for you. I don't know if that applies to VDSL, however.

¹ (Though it slowly got worse over the last year, with mtr currently showing 17 ms "best" as before, but 30 ms "average". But eh, at least the speed is decent.)

Written on 09 September 2023.
« How changing a ZFS filesystem's recordsize affects existing files
The roots of an obscure Bourne shell error message »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Sep 9 22:19:57 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.