Remote X Applications Over Slow Lines? 15
mwaddell asks: "One of the great things about X11 is the ability to run applications remotely. However, as one of the many *NIX users who use dialup to access the net, I have found that trying to run anything more complex than xcalc over phone lines is an exercise in frustration and patience. But for 99.9% of what I use remote apps for, I don't need color or any high level of detail. I'd be thrilled to have a window displayed in 8 shades of gray with oversized pixels if it would mean that it would react only slightly slower than a local app. Is this possible?" Would simple XResource changes help improve X11 performance for modem connections?
Tried dxpc ? (Score:1)
Latency (Score:2)
You see the same problem if you run X off of a server on a different continent... client-server only works for interactive processes if the client is within a few light-milliseconds of the server.
Re:VNC (Score:3)
I've had a lot of success simply using a browser with Java (by default you can connect to a machine at port 5800 + X server number). No need to install anything on a client. I used to run AfterStep with a background and Netscape fairly quickly. By default it's quicker than the regular client.
Of course, nowadays, I run single apps in over ssh with the -X (forward X, handles xhost and DISPLAY) and -C (compression) options. It seems to work well, though there is an initial delay.
CLI (Score:1)
"pixels" use a shell! X is for graphics hence: GUI
maken
Check your window manager (Score:3)
I used to run an Xterminal that was on one side of a fairly overloaded 56K line. This terminal did not run a local window manger - it logged in remotely via XDM. It ran fine once I did some tweaking to the window manager. Specifically, "fancy" window managers are horrid over slow links. Don't even consider something like CDE/KDE, Gnome or FWVM over a slow line. TWM, while very sparse, is an excellent window manager for slow lines.
Of course, if you run your window manager on your local box, it will have little effect on your network speed.
On a related topic, though: use the "older" applications. Remember that these applications were used across slower networks by the developers! Most new applications were developped on a single machine, with no network involved for the developer's display. As a result, that section of the code was probably never tuned. An example would be to use "xterm" instead of "konsole" (although I haven't tested these against each other; this is only an example)
Some other relevant information:
All I ran was a mining dispatch system, which had some fairly simple graphics (it tracked the mine's heavy equipment) on top of a CAD overlay of the mine. I was also able to use xterms and such fine. Don't even think about running Star Office or Netscape remotely, though -- too many messages have to pass back and forth. Desktop apps should stay on the desktop!
Differential X Protocol Compressor (Dxpc) (Score:3)
I've never used Dxpc [http] but my understanding of it is that it compresses all the X11 traffic on the fly. Used in combination with other tactics (e.g. using the lightweight apps/windowmanagers[1] like another poster recommended), should help your situation out.
I think there is some way to channel X11 over SSH, and further to finangle SSH into compressing the data stream, giving you compression as well as security. But I have absolutely no idea how to do that, so you're on your own in that regard. :-)
[1] if you want a lightweight windowmanager, definitely check out wm2 [all-day-breakfast.com], the rpm of which is 58Kb and at runtime (2x xterm, xdaliclock, xload, xsetroot -solid grey25, 1280x1024x16@100dpi) it looks to be taking up about 2.9 megs, of which a hair over a meg is actually shared. Note that wm2 is really minimal but then that's sorta the point. :-) Another low-usage window manager is aewm [red-bean.com], also interesting as it's homepage includes links to several other ultra-lights. (<--becuase let's face it, twm is U*G*L*Y and should not be tolerated in polite society, hah)
--
LBX = Low Bandwidth X (Score:5)
For more info, check out The LBX Mini-Howto [linuxdoc.org].
As some other posts have pointed out, the problem isn't entirely solveable (sp?), but LBX is at least one step in the right direction.
Have fun! //Johan
Workspot (Score:1)
VNC (Score:3)
It works like a frame buffer and only transmitts the changes within that buffer to the client.
The only disadvantage is that it requires setup on both sides. It is my preference over a slow connection.
Re:VNC (Score:2)
And ofcourse, vnc submits all mouse movements and other stuff while x just sends just the actual events and the client side does the care of the rest which might be the reason why x still functions faster.
I remember reading that vnc was meant to be ran on ATM networks (correct me if im wrong).
So, while vnc is truely a great piece of software, it wont prolly solve the speed problems.
--
Re:Latency (Score:1)
About all I can think would help is to use applications that don't animate pixmaps, and maybe tacking a compressor into the stream (even though X uses commands, they can be pretty verbose commands that a compressor may be able to pack down a bit more, especially if an X-aware compressor were made),
SSH compression (Score:2)
If that still isn't enough, I believe there is something called Low Bandwidth X (lbx) out there, and lightens things even more.
Re:Latency (Score:1)
VNC-TE / Tridia VNC (Score:2)
I haven't been able to try either of these two out, since Tridia's huge 10MB download and obnoxious website put me right off, and the links to VNC-TE were broken last time i looked.
However, highly-compressed VNC is probably the way to go, since X is a total dog compared to, dare i say it, MS Windown Terminal Server's RDP protocol.
Go-Global (Score:1)