Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re: Remote xterm strategy
Message-ID: <9001080655.AA27500@Larry.McRCIM.McGill.EDU>
Date: 8 Jan 90 06:55:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 55

> Rlogind uses select(2) to keep track of both the master side of the
> pty and the network connection instead of having separate reader and
> writer processes as is used by rlogin.  I don't know why rlogin
> doesn't do this also.  It's quite possible that there's no reason
> other than history.

Using two processes allows you to suspend the input side without
affecting the output side.  This suspends the rlogin but still allows
you to see remote output.  (How do you do it?  ~^Y, or whatever your
delayed-suspend character is set to.  Most people don't seem to be
aware that rlogin can do this.)

> Note that this means that most, if not all, of the performance
> difference between

>	Case 1:	xterm -e rlogin remote-host
>	Case 2:	rsh remote-host xterm -display local-host:0

> is going to be on the local-host since the remote-host runs the same
> number of processes and experiences [roughly] the same number of
> context switches in either case.  Things that *might* make case 2
> perform better than case 1 include:

>    1.	Slow network:  Extra bytes in the X protocol versus the rlogin
>	protocol.

>    2.	Slow network and/or slow remote-host: Extra transfers across
>	the net caused by mouse entry/exit and other possible X events
>	that wouldn't be experienced with case 2.  These extra transfers
>	also cause more context switches on the remote host.

>    3.	Slow remote-host: Xterm *may* be significantly more CPU hungry
>	than rlogind.  (I have no idea one way or the other whether this
>	may be true.)

All three of those things would make case 1 perform better than case 2,
not the other way around.

I don't know specifically about xterm.  However, I have my own terminal
emulator program, which I *suspect* is leaner than xterm (certainly
smaller and simpler).  Using this, I find that a local emulator plus an
rlogin is easier on the remote host than a remote terminal emulator.
(The remote-host in question is an overloaded VAX/750, whereas the
local-host is a Sun-3 with ample spare CPU.)

As for slow networks, it depends on what sort of slowness it is.  I
once used both an rlogin and an xterm over a network link with high
bandwidth but also high delay (round-trip times on the order of two
seconds), and there really wasn't much difference.  (I would certainly
expect a low-bandwidth link to produce different effects.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu