l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
January 6: Social gathering
Next Installfest:
Latest News:
Nov. 18: Club officer elections
Page last updated:
2003 May 22 10:55

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Exported X-windows - bandwidth req's
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Exported X-windows - bandwidth req's

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 19, 2003 at 03:39:53PM -0700, Richard Burkhart wrote:
> Would anyone happen to know how much bandwidth is needed to export windows
> from machine to machine?

  No bandwidth requirements, you just have to be patient in low
bandwidth situations.

> I'd like to go into Mozilla and figure out directly where the
> configuration is going wrong.

  Mozilla is going to be a little beefier than most other static=20
window things...=20

> But would I be out of my mind to try and do this between a pair of 56k
> modems (which of course won't upload any faster than 33,6)?

  I used to run X applications across a modem links... the biggest
problem you will have (as Mark pointed out) is latency.  If you are=20
navigating a menu, click only once and *wait* for the menu to appear,
then click on the next submenu and *wait*.  Don't get impatient thinking
the application has stopped responding...
   I have used NSCA Mosaic over modem before...

> How much information IS sent between machines for exported windows anyway?

  As everyone else says it depends on the application you are using.
An application that just puts of a window like xterm or xclock, is tiny...=
a program that constantly updates the screen will be much more.

  So since you say you want mozilla... here are numbers on how much data
is moved...  To launch mozilla, go to google, and run a search on=20
"Linux dxpc".

transfers about this much information:
  debug1: compress outgoing: raw data 326535, compressed 63537, factor 0.19
  debug1: compress incoming: raw data 701456, compressed 218201, factor 0.31

  Keep in mind over DSL <-> cable modem it takes at least a minute for
mozilla to start because there are a bazillion round-trip exchanges
before the window starts, after it is up and running interaction and
traffic is tiny in comparison.

The numbers above are from ssh gzip compression:
ssh -o Compression=3Dyes -o CompressionLevel=3D9 -X HOSTNAME APPLICATION

In order for this two work you need to reconfigure the ssh server to
allow X forwarding (on the remote machine):
  vi /etc/ssh/sshd_config
  # set: X11Forwarding yes

  If you already have a copy of mozilla running on your local desktop you
need to use an alternative profile (or else the remote mozilla command
will actually connect with the local mozilla and tell the local copy to=20
spawn another window, then the remote mozilla command will exit and you=20
will be running your local copy not theirs).

  ssh -X HOSTNAME mozilla -CreateProfile test
  ssh -X HOSTNAME mozilla -P test

  There is also a few X protocol compression agents which is specifically
designed for using X applications over low bandwidth links.... dxpc and
lbxproxy.  I have not used them before.  They are more complex, I will
just do an example with dxpc...

On local machine run:
  ssh -o Compression=3Dyes -o CompressionLevel=3D9 -t -L 4000:localhost:400=
0 \
    HOSTNAME 'dxpc & DISPLAY=3Dunix:8 mozilla -P test'

Then in another local window on the local machine run:
  dxpc -s1 localhost

=2E.. wait a while and mozilla will pop up.

Numbers for running that way are:
  debug1: compress outgoing: raw data 92332, compressed 38490, factor 0.42
  debug1: compress incoming: raw data 172456, compressed 150505, factor 0.87

  Mozilla will take quite a long time to start up because it appears to do
alot of talking to the X server before the window starts up, and you
have to wait for a few thousand round trips.

  lbxproxy might help... and also supports disconnected operation (like
screen does for terminals).

  You could also use VNC... which has an advantage that you can see=20
their desktop and figure out exactly what they are doing... but I=20
imagine it may require more bandwidth than running just the X application=
you want exported over one of the methods above... since you will be seeing
the _whole_ desktop.  Hopefully someone else can provide pointers for
doing this over ssh...=20

GPG key: http://simons-clan.com/~msimons/gpg/msimons.asc
Fingerprint: 524D A726 77CB 62C9 4D56  8109 E10C 249F B7FA ACBE

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.