Isaac Blake ([log in to unmask]) wrote:
: connections...  Further, I question how VT will play against Telnet...
 
To drop my $0.02... unless something totally unexpected comes out of
telnet, I would expect it to never catch up with the performance of the
VT service, mainly because of what telnet protocol is.  Simply put,
(unless telnet line mode can be effectively used), telnet - due to it's
design - will generate an order of magnitude greater network traffic
than VT, thus likely to saturate LAN cards with relatively low number of
users compared to VT.
 
For example, if a user types "HELLO MANAGER.SYS" over telnet, the logon
is going to translate into about 40..80 TCP packets over the network
(depending on TCP implementations and users typing speed).  The typing
speed is related to number of packets because tcp implementations
typically try to avoid sending "just ACK" packets - i.e. a tcp entity
often waits a little while before acknowledging data to see if there's
also some user data going to the same destination.  If the user types
slowly, TCP is going to time out and send just a tcp ack... and even
worse, in some cases the remote is going to respond to this by a tcp
sindow update...  i.e. the worst case is the following scenario for
each character typed:
 
  telnet client                                telnet host
    user types 'H' --------------------------->
    host echoes 'H' <-------------------------
    tcp times out, ack's one byte ------------>
    host sends a tcp window update<-----------
 
As said, this is the -worst- case and most tcp's are not so stupid that
they'd window update on 1 byte of buffer space freed up.  Normal would
be to see the character sent and echo back for each character - tcp ack's
would be shipped with data.
 
With VT, the same logon string is going to be 2 TCP packets over the net.
 
Given above, about 50 active users typing in telnet character mode at
about average typing speed of 3 chars/sec (6pkts/sec/user) cause about
300 pkts/sec or more traffic on host systems lanic card.  This is
independent of the host system - whether it is a 3000 or 9000 or whatever.
Not all lanic cards can handle that amount of traffic.
 
About MAC specs, both Ethernet and IEEE 802.3 use the same CSMA/CD media
access method and given the speed (10MB/s) and the media access specs,
this gives us couple other limits on how many packets per sec can be
on that media.  If using max packet size, we are limited to ~800 pkt/sec
and with the smallest legal pkt size we are in the range of 15,000 pkts/sec.
Also, given that ethernet typically dies with collisions after ~33% traffic
level, the realistic figures become ~250 max size and ~5000 min size
packets/sec.  Also, one's LAN is typically cluttered with all kinds of
traffic, not just telnet traffic to one host from multiple clients.
 
As said in the beginning, I don't know how telnet is going to be using/
be used in terms of character mode vs. line mode - my guess is that
in order to work with typical ux-world applications (like vi, shells etc)
it has to be in character mode most of the time.  And that is going
to translate into pretty bad performance and high network utilization.
 
If line mode can be used -or- if both VT and telnet are used to interface
with an application doing 1 byte reads -- I would expect their performances
to be close to each other and that's the best case for telnet.  I don't
expect block-mode to work through telnet and VT is going to continue to
have a big performance advantage there.
 
As a bottom line -- and this is all my opinion - not reflecting any of
my employer's -- I would expect that a high-end 3000 - say 995 with
a few CPU's should be able to handle all 1250 max currently supported
number of VT-sessions plus another 1000 DTC sessions with relative ease.
This based on 992-400's I've seen handling about ~900 users (most VT)
without response time problems.  Telnet sessions will generally
have more CPU overhead and more than enything else, I expect them to
saturate LAN interface(s).
 
 =======================================================================
Eero Laurila                            Hewlett-Packard
email:  [log in to unmask]                 Commercial Systems Division
                                        Networking R&D lab
                                        NS Services
 
The thoughts expressed herein are mine and do not reflect those of my
employer, or anyone with common sense.