>>>>> "Frederick" == Frederick Bruckman <fb@enteract.com> writes:

    Frederick> On Wed, 9 Aug 2000, Richard Rauch wrote:
    >> It seems that forwarding of X _is_ working.  However, it is
    >> operating very slowly, and I'm not yet sure why.
    >> 
    >> What I can see is that for some reason X protocol packets are
    >> being sent over my dial-up Internet connection at the sametime
    >> as between the two (Ethernet-connected) machines that I'm
    >> using.

    Frederick> Are you sure about that? Run "tcpdump -i ppp0".

    >> This seems to only happen with an X client running on one
    >> machine (with the modem) and the X server running on the other
    >> machine.  This greatly slows down all display activity (opening
    >> a window, as well as refreshing contents, as of an xterm).

    Frederick> It could also be that the compression/encryption is
    Frederick> overloading your gateway/client host. What kind of
    Frederick> machine is it? I use blowfish, no compression for local
    Frederick> connections, and ssh forwarding works OK, for some
    Frederick> things, even to a slow Quadra (mac68k). xterms, knews,
    Frederick> are fine, but battleball doesn't perform well at all.

Richard and Frederick: are you making use of LBX (Low-Bandwidth X)
anywhere in your connections?  Through a modem, I'm not surprised that
X works, albeit verrrry slowwwwly, despite any encryption.

Using LBX is easy.  At it's simplest, I do this:

  home$ xhost +
  access control disabled, clients can connect from any host
  home$ rlogin office
  office$ lbxproxy :100 -display home:0.0 &
  office$ arbitrary-xclient -display :100 ... &
  office$ 

Of course, there's nothing stopping me from starting X11 clients on
any relevant machines at the office, as long as they're told to
'... -display office:100 ...'.  They all end up drawing on home:0.0!

I must admit, I haven't tried battleball, but xemacs and netscape work
fine, if with not unreasonable lags when transmitting large bitmaps.



    >> Because I happened to be downloading a large .tar.gz file for
    >> pkgsrc, the process was running even more slowly, and appeared
    >> to freeze without even opening a window.  Since I didn't know
    >> that it was using the modem (and still don't know WHY it was
    >> using the modem), I assumed that X forwarding was broken.

You might be able to speed up this sort of thing by tweaking the
MTU/MRU of the PPP running over the modem link.  If the MTU is the
default value of 1500, say, then small arbitrary packets (X-requests,
telnet keystrokes, and their acknowledgements/character echos, etc.)
must be queued while-so-ever a bulk data transfer is in progress,
which, in my (somewhat limited?) experience, chokes pretty much all
interactive sessions until the FTP is complete, at which point they
rocket along again, unimpeded.  W Richard Stephens talks about this
somewhere in the early parts of his "TCP/IP Illustrated Vol 1", though
he speaks in relation to SLIP, his arguments are still relevant to
PPP.

There is a potential down-side to shrinking your MTU: you might find
that your happy web-browsing is sometimes broken; this has to do with
the Path MTU Discovery algorithm, which works via ICMP packets---for
sites where ICMP packets are filtered, you'll experience weirdness.

--
Kevin.