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.