NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/os2/networki/1265

Text File | 1992-09-08 | 3.6 KB | 70 lines

Newsgroups: comp.os.os2.networking
Path: sparky!uunet!newsgate.watson.ibm.com!news.ans.net!ans.net!db3l
From: [e-mail] (David Bolen)
Subject: Re: TCP/IP 1.2.1 remote telnet session too slow!
Sender: [e-mail] (News Administrator)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of Tue, 8 Sep 1992 05: 35:20 GMT
Date: Tue, 8 Sep 1992 12:00:15 GMT
References: <[e-mail]> <rx3yaj=@rpi.edu>
Organization: Advanced Network & Services, Inc. - Elmsford, NY
Lines: 57

In article <rx3yaj=@rpi.edu> [e-mail] (A. Andre Asselin) writes:

>[e-mail] (alann lopes) writes:
>
>>  Whenever I telnet into our os2 machines running tcp/ip 1.2.1
>>  and the machine is doing some cpu intensive task, the remote
>>  telnet session is unusable.
>
>Alann,
>   Unfortunately, this is an artifact of how the telnet server is implemented.
>Whenever the screen is modified, the telnet server will generally repaint the
>whole screen, rather than send a particular escape sequence to accomplish the
>same thing.  This shows up particularly with screen scrolling.  It is
>unfortunate, but the way OS/2 allows access to the contents of a screen, it
>would be pretty complicated to implement it any other way.

Just to be accurate - this behavior does depend upon the terminal type that
is being used.  For example, if you come in via a VT100, then any scrolling
of regions that comprise the full width of the screen are accomplished very
efficiently (using an ESC [ # M region scroll command (# = lines)).  However,
if you come in via an ANSI terminal (such as the ANSITERM telnet supplied
with OS/2), it has no equivalent scrolling function, so the telnet server
allows OS/2 to perform the scroll, and then sends the complete updated region
to the client.  In a full-screen scroll case, this does result in the entire
screen being sent.  The VT100 emulation does the same thing in the event
that a scrolling region other than full-line width is used, since the VT100
can only define a scrolling region in terms of lines.

Mostly because of this, you should find that in general VT100 results in a
smaller amount of information being transmitted over the net, although ANSI
gives you full character set support and color.  However, on the flip side,
the current VT100 emulator is much slower than ANSITERM (which just gives
the characters to OS/2), so it can be a toss-up depending on what you are
trying to optimize.

Something that I have played with, but never quite completed due to lack of
time is to write an OS/2 terminal type driver, such that the OS/2 VIO calls
got shipped across basically intact.  This should give a reasonably good
traffic/performance tradeoff.

Oh, and I should also mention that if you use the telnet enhancer that
Mikael put up on ftp-os2 recently, then from another OS/2 machine ANSITERM is
much better than VT100, since TN_ENH waits a second or two and then sends
the result of a number of operations, rather than trying to send a full
screen for each scroll operation.  Unfortunately in this case, TN_ENH actually
sends more information than the native VT100 emulation would have, so that
plus the additional VT100 processing on the client end, makes VT100 definitely
perform worse than ANSITERM.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: [e-mail]      /
  |   Advanced Network & Services, Inc.   \   Phone: [phone]   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: [phone]    \
\-----------------------------------------------------------------------/