Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!tucker From: tucker@smsc.sony.com (Tim Tucker 817) Newsgroups: comp.protocols.tcp-ip Subject: Re: LAT Message-ID: <1991Jan13.001403.2933@smsc.sony.com> Date: 13 Jan 91 00:14:03 GMT Organization: Sony Microsystems Corp. Lines: 33 > - LAT causes less of a burden on the CPU and the network > "In preliminary test using KI Research's KiNet, DR Labs found > the DEC's LAT protocol imposed lower overhead on both the host > CPU and the network than TELNET. For example, with 45 active > TELNET session on a Mips M/120-5 system, the CPU had zero > percent idle time, meaning that it was overload, and only 4.4 > percent of the network bandwidth was utilized. With 64 active > LAT sessions to the same machine, the CPU was still 50 percent > idle, and only 2 percent of the network bandwidth was > utilized. This difference is due in large part to the fact > that LAT does not use the full DECnet stack, whereas TELNET > uses the full TCP/IP stack." (Lee Schlesinger, Digitial > Review, August 27, 1990) Hmmm, in theory LAT is cheaper than TCP/IP, but I wonder if Digital Review was comparing apples and oranges? Most likely the TCP/IP implementation was based on BSD. That means the user space BSD telnet/rlogin daemons are used. These daemons, I'm not knocking them, cause a very heavy context switch burden under high multi-user loads. Several years ago I worked a complete kernel implementation of both telnet and rlogin for a BSD based system (the Gould UTX/32 2.0 OS). It turned out to be pretty easy. We used the public domain reference code that has been on the archives for years as an example on how to get started. The result was exactly what you would expect. We went upto 128 users, I think, during QA tests and still meet our application load requirements (bid requirements). It would be interesting to see how these LAT kernel stacks compare against a lean kernel implementation of TELNET or RLOGIN. Tim Tucker tucker@smsc.sony.com