Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!decwrl!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.windows.x
Subject: Re: Remote xterm strategy
Message-ID: <43533@lll-winken.LLNL.GOV>
Date: 8 Jan 90 05:21:40 GMT
References: <90Jan6.054031est.2293@neat.cs.toronto.edu> <6517@ogicse.ogc.edu> <32711@news.Think.COM> <1990Jan7.213940.11542@smsc.sony.com> <43510@lll-winken.LLNL.GOV>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov.UUCP (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 46


| From: per@erix.ericsson.se (Per Hedeland)
| 
| > From: casey@gauss.llnl.gov (Casey Leedom)
| > 
| >   Even the remote-host which doesn't see any more context switching is
| > forced to context switch between two user level processes instead of only
| > one.
| 
| To be perfectly fair, there is only one rlogind process running on the
| remote host, handling both directions.

  Hhmmm.  I'm sorry.  I could have sworn I remembered two rlogind
processes.  I guess I'm going to have to slow down my output here.  I'm
making way too many mistakes.  (You don't want to hear about it.)

  In any case, I see that Per is right.  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.

  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.)

Casey