Path: utzoo!attcan!uunet!samsung!usc!snorkelwacker!bloom-beacon!THINK.COM!rlk From: rlk@THINK.COM (Robert L. Krawitz) Newsgroups: comp.windows.x Subject: Remote xterm strategy Message-ID: <9001081503.AA06462@underprize.think.com> Date: 8 Jan 90 15:03:04 GMT References: <43533@lll-winken.LLNL.GOV> Sender: rlk@think.com Organization: The Internet Lines: 28 One thing I notice everyone talking about in terms of this problem is the number of {context switches,bytes,packets} per input keystroke. I submit that, particularly on a fast workstation, a more important criterion in many cases is the amount of load measured in (insert your favorite here) per line, or per number of bytes, of output. On a fast machine (such as any of the new RISC workstations), it's impossible to type fast enough to make the machine notice (a fast typist types at 100 WPM, which is less than 9 characters per second). Even ten context switches per keystroke is only 90 per second, which isn't hard to maintain. Given that users of an X-based editor don't normally type large quantities of text into an xterm, the sustained overhead is somewhat less. It's also impossible to type into more than one window at any one time. However, it's very easy for a program or three to spit out data at a very high rate. Then the issue becomes network traffic (rlogin consumes much less than X) vs. local context switches (the remote xterm does many fewer). A very useful program that no one's written is xrlogin (or xtelnet, or xsupdup). This combines xterm and rlogin in one process (it speaks rlogin protocol itself), and does not allocate a pty on the local machine. On the other hand, it requires a host to be specified on the command line. Given that a major use of xterm is to rlogin to a remote machine, this would seem a very useful program to me... ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111