"""
the biggest problem with X is that it frequently takes a _lot_ of round trip messages to do standard things.
"""
True. Watching an X session over a dial up modem (external, with tx/rx lights) is quite interesting. Not only are there a lot of round trips, but it appears that everything happens in serial fashion with only one request or response in the pipe at any given time. In the modem's LEDs you can clearly see "request, response, request, response, request, response...".
Many people think that X needs bandwidth. It actually isn't such a bandwidth hog. Others correctly point out the round trip issue. But rarely have I heard anyone comment upon the serialized nature of the protocol. And that looks like the real performance killer to me. At least over any sort of WAN. At Ethernet latencies it's likely not a problem at all.
Posted Jul 26, 2009 9:28 UTC (Sun) by njs (guest, #40338)
[Link]
When people complain about X and round trips, it's the serialization issue that they're talking about. No-one cares if there's *one* round trip between a user action and a visible response (or if they do, there's nothing that could be done about it anyway), it's the fact that you have to wait for one response before you can make the next request that turns round-trip latency into your bottleneck.
That's why relatively crude protocols like VNC can completely outclass X -- sure, now you're stuffing giant blocks of pixels down the network pipe and taking way more bandwidth, but those giant blocks of pixels have no dependencies -- so instead of waiting around all the time, you can just saturate the pipe. (rsync uses a similar strategy; see also pipelined SMTP, IMAP, HTTP, ...)