On 12 Nov, this message from [EMAIL PROTECTED] echoed through cyberspace: > Not sure if this is the correct list, but I'll give it a try. We're trying > to move from M$ to Linux, using Netraverse via X to diskless (or minimal - > like a ThinkNic) workstations. We're in proof-of-concept mode here, and are > trying to serve this up via the internet to a remote station. While this > seems to work very speedily over my ethernet connection, it is horribly slow > over an ISDN (here in Texas) ->T1 connection (in Tennessee).
Hmmm, X over ISDN dial-up? at 64kb/s? That _will_ be damn slow. > Looking at the > bandwidth, it is generally using about 3K bytes per second, but doing little > to nothing on the remote screen. Screen refreshes that take a second or so > locally are taking up to 3 MINUTES on the remote, with a constant 3K > bytes/sec of traffic. Occasionally we see a burst of 10Kbytes/sec, but not > often, and there appears to be no connection with that burst and the rate of > screen refresh. I don't know why you see the bandwidth useage pattern you describe.... > ssh -X -f user@localserver <application> > > This example came from the Netraverse manual, and, again, it works very > speedily over my ethernetwork, served from the same machine that is giving > it up so slowly. Is there a better way to do this? Are there settings to > speed this up? - Have a look at Low-bndwidth X (LBX), but I'm not sure that will gain you much. Anyone have any experience with it? - Make sure you enable compression in ssh. In my experience that will give you a five-fold increase in perceived performance for X traffic. Make sure however that both ends have enough horsepower to do the compression/decompression. But in general, expect a huge performance penalty when working over dial-up. The two things that kill you are: - delay: X does things in lots of small requests going back and forth between client and server. You will get the delay penalty each time... - bandwidth: X is not optimised for low bandwidth. Other 'remote desktop' protocols might work better in that situation. You might want to try VNC or one of the MS remote desktop protocols, if that's an option in your case. Cheers Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED] | http://www.cpu.lu/~mlan | Learn Always. " _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
